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Cornell  University  2012 

We  are  entering  an  era  in  which  federated  information  systems  are  widely  used 
to  share  information  and  computation.  Federated  systems  support  new  services 
and  capabilities  by  integrating  computer  systems  across  independent  adminis¬ 
trative  domains.  Each  domain  has  policies  for  security,  but  does  not  fully  trust 
other  domains  to  enforce  them.  This  dissertation  explores,  in  two  parts,  the  chal¬ 
lenge  of  designing  and  building  federated  information  systems  that  are  secure 
and  reliable  while  supporting  mutually  distrusting  participants. 

First,  this  dissertation  presents  Fabric,  a  new  system  and  language  for  build¬ 
ing  secure  federated  information  systems.  Fabric  allows  heterogeneous  network 
nodes  to  securely  share  information  and  computation  despite  mutual  distrust.  It 
uses  optimistic,  nested  transactions  to  ensure  global  consistency,  and  has  a  peer- 
to-peer  dissemination  layer  for  better  availability  and  load  balancing.  Fabric's 
high-level  programming  language  provides  a  rich,  Java-like  object  model,  and 
keeps  distribution  and  persistence  largely  transparent  to  programmers.  It  sup¬ 
ports  data  shipping  and  function  shipping:  both  information  and  computation 
can  move  between  nodes  to  meet  security  requirements  or  to  improve  perfor¬ 
mance.  Confidentiality  and  integrity  policies  on  objects  are  enforced  through  a 
combination  of  compile-time  and  run-time  mechanisms.  Results  from  building 
Fabric  applications  suggest  that  Fabric  has  a  clean  and  concise  programming 
model,  offers  good  performance,  and  enforces  security. 

Next,  this  dissertation  examines  the  security  implications  of  providing  refer¬ 
ential  integrity  in  a  federated  system.  Referential  integrity  ensures  that  named 
resources  can  be  accessed  when  needed.  This  is  an  important  property  for  re- 


liability  and  security.  However,  the  attempt  to  provide  referential  integrity  can 
itself  lead  to  security  vulnerabilities  that  are  currently  not  well  understood.  This 
dissertation  identifies  three  such  referential  security  vulnerabilities,  and  formal¬ 
izes  security  conditions  corresponding  to  their  absence.  A  language  model  cap¬ 
tures  key  aspects  of  programming  distributed  systems  with  named,  persistent 
resources  in  the  presence  of  an  adversary.  A  new  type  system  is  proved  to  en¬ 
force  the  conditions  for  referential  security. 
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CHAPTER  1 


INTRODUCTION 

Distributed  information  systems  network  computers  together  to  provide  fast, 
efficient  access  to  data  and  computation.  We  rely  on  complex,  distributed  in¬ 
formation  systems  for  many  important  activities.  Government  agencies,  banks, 
hospitals,  schools,  and  many  other  enterprises  use  distributed  information  sys¬ 
tems  to  manage  information  and  interact  with  the  public. 

These  systems  often  have  security  requirements,  of  which  there  are  three 
central  goals:  confidentiality,  that  information  be  protected  from  unauthorized 
disclosure;  integrity,  that  information  be  protected  from  unauthorized  modifica¬ 
tion;  and  availability,  that  information  be  protected  from  loss  of  use  [18].  Viola¬ 
tions  of  these  requirements  can  have  financial,  legal,  and  ethical  consequences. 
Current  practice  does  not  offer  general,  principled  techniques  for  implementing 
the  functionality  of  these  systems  while  also  satisfying  their  security  require¬ 
ments. 

The  trend  towards  integration  makes  the  security  problem  ever  more  im¬ 
portant  and  difficult.  Whereas  distributed  information  systems  are  operated  by 
individual  administrative  domains ,  federated  systems  provide  new  services  and 
capabilities  by  connecting  these  systems  together.  However,  each  domain  has 
its  own  policies  for  security,  and  does  not  fully  trust  other  domains  to  enforce 
them.  Future  information  systems  will  need  to  function  correctly  and  securely 
despite  having  code  and  data  distributed  across  these  trust  boundaries. 

This  dissertation  examines  in  two  ways  the  challenge  of  designing  and  build¬ 
ing  federated  information  systems  that  are  secure  and  reliable.  The  first  half 
presents  the  design  and  implementation  of  Fabric,  a  platform  for  building  fed¬ 
erated  information  systems  with  confidentiality  and  integrity  assurances. 
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While  Fabric  offers  confidentiality  and  integrity  assurances,  these  alone  are 
not  sufficient  for  building  secure  and  reliable  federated  systems.  The  challenge 
is  made  more  difficult  because  information  is  not  merely  bits — it  has  structure. 
Information  resources  use  names  to  refer  to  other,  perhaps  remote,  resources. 
For  example,  web  pages  can  have  hyperlinks  to  other  pages,  tuples  in  relational 
databases  can  have  foreign  keys  that  refer  to  other  tuples  in  the  database,  and 
objects  in  distributed  object  systems  can  point  to  other  objects  in  the  system. 
The  precise  details  of  how  references  are  represented  are  not  germane,  so  we 
refer  to  all  these  constructs  collectively  as  references.  Similarly,  we  use  the  term 
objects  to  refer  generically  to  information  resources  that  are  connected  by  refer¬ 
ences,  whether  web  pages,  database  tuples,  or  distributed  objects.  Regardless 
of  the  kind  of  system,  security  and  reliability  vulnerabilities  are  created  when 
references  cross  trust  boundaries  in  a  distributed  system. 

The  second  half  of  this  dissertation  identifies  three  kinds  of  referential  security 
vulnerabilities,  a  class  of  availability  vulnerabilities  that  appear  in  federated  in¬ 
formation  systems  with  persistent  information.  It  formally  characterizes  these 
vulnerabilities  and  explores  a  language-based  approach  for  modelling,  analyz¬ 
ing,  and  preventing  them. 

1.1  Example 

Epidemiological  research  is  one  domain  that  would  benefit  from  a  secure,  fed¬ 
erated  information  system.  Because  of  patient  confidentiality  concerns,  re¬ 
searchers  have  limited  access  to  epidemiological  data  in  the  US  and  Canada, 
especially  for  STIs  such  as  HIV/ AIDS.  When  available,  data  sets  are  highly 
regional — often  restricted  to  a  single  city — and  in  some  cases  must  be  obtained 
in  person  or  hand-delivered  by  courier.  The  data  is  incomplete  because  it  does 
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Figure  1.1:  A  medical  example 


not  include  full  patient  records.  Instead,  it  is  derived  from  population  surveys 
and  diagnosis  forms  that  are  unable  to  fully  anticipate  researchers'  needs  [75].  A 
secure,  federated  information  system  would  allow  researchers  to  directly  mine 
patient  records  for  real-time  epidemiological  trends  while  protecting  patient 
confidentiality. 

To  illustrate  the  challenges,  consider  the  scenario  in  Figure  1.1.  A  patient,  Al¬ 
ice,  has  two  doctors — a  general  practitioner  and  a  psychiatrist — and  has  given 
consent  for  her  medical  record  to  be  used  anonymously  for  research.  The  med¬ 
ical  record  is  kept  in  a  federated  information  system.  This  not  only  provides  re¬ 
searchers  with  direct  access  to  her  medical  data,  but  her  two  doctors  at  separate 
medical  institutions  can  securely  and  quickly  share  her  medical  information.1 

1The  ability  of  doctors  to  effectively  collaborate  on  patient  information  is  important.  Accord¬ 
ing  to  a  1999  Institute  of  Medicine  study,  at  least  44,000  US  deaths  annually  result  from  medical 
errors,  with  incomplete  patient  information  identified  as  a  leading  cause  [40]. 
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Automated  sharing  of  patient  data  poses  difficulties.  First,  the  security  and 
privacy  policies  of  the  two  institutions  must  be  satisfied  (as  mandated  by  the 
Health  Insurance  Portability  and  Accountability  Act  (HIPAA)  [34]  in  the  US), 
restricting  which  information  can  be  shared  or  modified  by  the  two  institutions. 
While  Alice's  doctors  might  have  access  to  her  complete  medical  record,  the 
researchers'  view  of  the  record  should  not  contain  any  personally  identifying 
information,  such  as  Alice's  address  or  phone  number. 

Second,  the  patient  record  may  be  updated  by  both  institutions  as  treatment 
progresses,  yet  the  record  should  be  consistent  and  up  to  date  when  viewed  by 
the  researcher  and  from  the  two  institutions.  It  is  inadequate  to  simply  transmit 
a  copy  of  the  record  in  a  common  format  such  as  XML,  because  the  copy  and  the 
original  are  likely  to  diverge  over  time.  Instead,  the  researcher  and  institutions 
should  have  easy,  secure,  consistent  and  efficient  access  to  what  is  logically  a 
single  patient  record. 

Third,  the  record  is  likely  composed  of  several  objects,  with  references  to 
other,  perhaps  remote,  objects.  For  example,  an  object  representing  a  prescrip¬ 
tion  might  refer  to  an  object  at  a  pharmaceutical  company,  identifying  the  pre¬ 
scribed  drug  and  providing  information  about  it,  such  as  contraindications,  side 
effects,  and  drug  interactions.  This  is  useful,  because  when  the  pharmaceu¬ 
tical  company  adds  new  information  about  the  drug,  it  is  instantly  reflected 
in  Alice's  medical  record.  However,  the  referential  integrity  of  Alice's  record  is 
now  dependent  on  the  pharmaceutical  company:  information  in  Alice's  medi¬ 
cal  record  becomes  missing  if  the  drug  information  is  deleted  or  is  temporarily 
unavailable.  It  is  therefore  important  that  either  the  pharmaceutical  company 
be  trusted  to  enforce  this  referential  integrity,  or  that  users  of  Alice's  medical 
record  be  prepared  for  a  potential  failure  in  referential  integrity. 
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1.2  Contributions  of  this  dissertation 


1.2.1  Secure  federated  computation  and  storage 

This  dissertation  presents  the  design  and  implementation  of  Fabric,  a  federated 
system  that  supports  secure,  shared  access  to  information  and  computation,  de¬ 
spite  distrust  between  cooperating  entities.  The  goal  of  Fabric  is  to  make  secure 
distributed  applications  much  easier  to  develop,  and  to  enable  the  secure  inte¬ 
gration  of  information  systems  controlled  by  different  organizations. 

To  achieve  this  goal.  Fabric  provides  a  shared  computational  and  storage 
substrate  implemented  by  an  essentially  unbounded  number  of  Internet  hosts. 
As  with  the  Web,  there  is  no  notion  of  an  "instance"  of  Fabric.  Two  previously 
non-interacting  sets  of  Fabric  nodes  can  interact  and  share  information  without 
prior  arrangement.  There  is  no  centralized  control  over  admission:  new  nodes, 
even  untrustworthy  nodes,  can  join  the  system  freely. 

Untrustworthy  nodes  pose  a  challenge  for  security.  The  guiding  principle  for 
security  in  Fabric  is  that  one's  security  should  never  depend  on  components  of 
the  system  that  one  does  not  trust.  Fabric  provides  security  assurance  through 
a  combination  of  mechanisms  at  the  language  and  system  levels. 

Fabric  gives  programmers  a  high-level  programming  abstraction  in  which 
security  policies  and  some  distributed  computing  features  are  explicitly  visible 
to  the  programmer.  Programmers  access  Fabric  objects  in  a  uniform  way,  even 
though  the  objects  may  be  local  or  remote,  persistent  or  non-persistent,  and 
object  references  may  cross  between  Fabric  nodes. 

The  Fabric  programming  language  is  an  extension  to  the  Jif  programming 
language  [53,56],  in  turn  based  on  Java  [30].  Fabric  extends  Jif  with  support  for 
distributed  programming  and  transactions.  Tike  Jif,  Fabric  has  several  mech- 
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anisms,  including  access  control  and  information-flow  control,  to  prevent  un¬ 
trusted  nodes  from  violating  confidentiality  and  integrity.  All  objects  in  Fabric 
are  labelled  with  policies  from  the  decentralized  label  model  (DLM)  [54],  which 
expresses  security  requirements  in  terms  of  principals  (e.g.,  users  and  organi¬ 
zations).  Object  labels  prevent  a  node  that  is  not  trusted  by  a  given  principal 
from  compromising  the  security  policies  of  that  principal.  Therefore,  Fabric  has 
fine-grained  trust  management  that  allows  principals  to  control  to  what  extent 
other  principals  (and  nodes)  can  learn  about  or  affect  their  information. 

To  achieve  good  performance  while  enforcing  security.  Fabric  supports  both 
data  shipping,  in  which  data  moves  to  where  computation  is  happening,  and 
function  shipping,  in  which  computations  move  to  where  data  resides.  Data 
shipping  enables  Fabric  nodes  to  compute  using  cached  copies  of  remote  ob¬ 
jects,  with  good  performance  when  the  cache  is  populated.  Function  shipping 
enables  computations  to  span  multiple  nodes.  Inconsistency  is  prevented  by 
performing  all  object  updates  within  transactions,  which  are  exposed  at  the  lan¬ 
guage  level.  The  availability  of  information,  and  scalability  of  Fabric,  are  in¬ 
creased  by  replicating  objects  within  a  peer-to-peer  dissemination  layer. 

Of  course,  there  has  been  much  previous  work  on  making  distributed  sys¬ 
tems  both  easier  to  build  and  more  secure.  Prior  mechanisms  for  remotely 
executing  code,  such  as  CORBA  [61],  Java  RMI  [62],  SOAP  [33]  and  web  ser¬ 
vices  [50],  generally  offer  only  limited  support  for  information  security,  consis¬ 
tency,  and  data  shipping.  J2EE  persistence  (EJB)  [23]  provides  a  limited  form 
of  transparent  access  to  persistent  objects,  but  does  not  address  distrust  or  dis¬ 
tributed  computation.  Peer-to-peer  content-distribution  and  wide-area  storage 
systems  (e.g.,  [20,42,65,68])  offer  high  data  availability,  but  do  little  to  ensure 
that  data  is  neither  leaked  to  nor  damaged  by  untrusted  users,  nor  do  they  en- 
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sure  consistency  of  mutable  data.  Prior  distributed  systems  that  enforce  con¬ 
fidentiality  and  integrity  in  the  presence  of  distrusted  nodes  (e.g.,  [12, 80,  81]) 
have  not  supported  consistent  computations  over  persistent  data. 

Fabric  integrates  many  ideas  from  prior  work,  including  compile-time  and 
run-time  information  flow,  access  control,  peer-to-peer  replication,  and  opti¬ 
mistic  transactions.  This  unique  integration  makes  possible  a  higher-level  pro¬ 
gramming  model  that  simplifies  reasoning  about  security  and  consistency.  In¬ 
deed,  it  does  not  seem  possible  to  provide  a  high-level  programming  model 
like  that  of  Fabric  by  simply  layering  previous  distributed-systems  abstractions. 
Several  new  ideas  were  also  needed  to  make  Fabric  possible: 

•  A  programming  language  that  integrates  information  flow,  persistence, 
transactions,  and  distributed  computation. 

•  A  trust  ordering  on  information-flow  labels,  supporting  reasoning  about 
information  flow  in  distributed  systems. 

•  An  integration  of  function  shipping  and  data  shipping  that  also  enforces 
secure  information  flows  within  and  among  network  nodes. 

•  A  way  to  manage  transactions  distributed  among  mutually  distrusting 
nodes,  and  to  propagate  object  updates  while  enforcing  confidentiality 
and  integrity. 

Fabric  does  not  require  application  developers  to  abandon  other  standards 
and  methodologies;  it  seems  feasible  for  Fabric  to  interoperate  with  other  stan¬ 
dards.  In  fact.  Fabric  already  interoperates  with  existing  Java  application  code. 
It  seems  feasible  to  implement  many  existing  abstractions  (e.g.,  web  services) 
using  Fabric.  Conversely,  it  seems  feasible  to  implement  Fabric  nodes  by  encap¬ 
sulating  other  services  such  as  databases.  We  leave  further  work  on  interoper¬ 
ability  to  the  future. 
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1.2.2  Referential  security 

Fabric  provides  confidentiality  and  integrity  through  a  combination  of 
information-flow  control  and  access  control.  However,  experience  building 
Fabric  applications  has  revealed  security  and  reliability  vulnerabilities  result¬ 
ing  from  object  references. 

References  create  security  issues  because  they  introduce  dependencies  be¬ 
tween  different  parts  of  the  system.  We  say  that  a  system  has  referential  integrity 
if  a  reference  can  be  relied  upon  to  continue  pointing  to  the  same  object.  This 
is  both  an  availability  and  an  integrity  property.  Referential  integrity  fails  when 
an  object  is  deleted  while  a  reference  to  it  still  exists,  resulting  in  a  dangling  ref¬ 
erence  (an  availability  failure),  or  when  the  reference  points  to  a  different  object 
altogether  (an  integrity  failure).  Because  Fabric  does  not  address  availability. 
Fabric  programs  can  encounter  dangling  references. 

Referential  integrity  appears  in  many  guises.  We  use  the  term  in  a  more 
general  sense  than  in  the  database  literature,  where  referential  integrity  is  an 
important  aspect  of  the  relational  model  [17].  The  Web  is  a  system  whose  lack 
of  referential  integrity  is  well  known:  the  referent  of  a  hyperlink  can  be  deleted, 
leading  to  the  familiar  "404"  error.  Referential  integrity  is  also  an  important 
property  for  programming  language  design;  in  programming  languages  that 
lack  referential  integrity,  such  as  C,  dangling  pointers  are  a  serious  problem.  To¬ 
day,  many  languages  have  automatic  garbage  collection,  allowing  the  automatic 
reclamation  of  memory  while  preserving  referential  integrity. 

While  absolute  referential  integrity  is  desirable,  it  cannot  be  achieved  in  a 
federated  system  such  as  Fabric:  referential  integrity  is  necessarily  limited  by 
the  trustworthiness  of  the  node  (or  nodes)  storing  the  referent  object.  Therefore, 
we  generalize  referential  integrity  to  systems  where  nodes  are  partially  trusted. 
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In  a  federated  system,  referential  integrity  must  be  balanced  against  other 
security  and  reliability  properties.  Indeed,  violations  of  referential  integrity  are 
only  the  first  of  three  referential  security  vulnerabilities  considered  in  this  disser¬ 
tation.  In  a  system  with  referential  integrity,  a  reference  to  an  object  is  a  promise 
to  the  referrer  that  the  object  will  not  move  or  disappear.  It  must  be  persis¬ 
tent.  Therefore,  reachability  implies  persistence,  as  in  various  object-oriented 
databases  (e.g.,  [4,8])  and  also  in  marshalling  mechanisms  such  as  Java  serializa¬ 
tion.  However,  if  all  reachable  objects  are  persistent,  objects  can  become  acciden¬ 
tally  persistent  because  they  are  unexpectedly  reachable.  Accidental  persistence 
can  inflate  resource  consumption,  leading  to  poor  performance  and  system  fail¬ 
ure.  This  problem  is  familiar  to  programmers  who  have  used  Java  serialization. 
Avoiding  accidental  persistence  is  our  second  goal. 

The  third  goal  is  preventing  what  we  call  storage  attacks.  Referential  integrity 
prevents  discarding  reachable  objects.  But  this  gives  an  adversary  a  means  to 
mount  a  denial-of-service  attack.  The  adversary  creates  references  to  objects  in¬ 
tended  to  be  discarded,  preventing  reclamation  and  perhaps  exhausting  avail¬ 
able  storage  space. 

In  summary,  the  second  part  of  this  dissertation  studies  the  problem  of  pro¬ 
gramming  in  distributed  object  systems  while  preventing  three  kinds  of  referen¬ 
tial  vulnerabilities:  dangling  pointers  that  violate  referential  integrity,  acciden¬ 
tal  persistence  that  leaks  storage,  and  storage  attacks  that  consume  resources. 
While  recent  work  has  explored  programming  models  and  languages  for  build¬ 
ing  federated  systems  (e.g.,  [42]),  these  referential  vulnerabilities  have  not  been 
clearly  identified  or  addressed  in  prior  work. 

This  dissertation  formalizes  referential  vulnerabilities  in  terms  of  security 
properties  corresponding  to  their  absence.  These  referential  security  properties  are 
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formalized  in  the  context  of  a  simple  programming  language  that  captures  the 
key  elements  of  distributed  programming  in  a  federated  system  with  persistent 
information  and  pointers.  A  new  type  system  is  defined  to  enforce  these  se¬ 
curity  properties,  ensuring  that  the  system  is  secure  and  reliable.  Because  these 
properties  can  be  viewed  as  integrity  properties,  the  language  must  also  enforce 
integrity  in  the  information-flow  sense.  The  correctness  of  security  enforcement 
by  the  type  system  has  been  proved. 

1.3  Dissertation  outline 

The  rest  of  this  dissertation  is  structured  as  follows.  Chapter  2  presents  the  de¬ 
sign  and  implementation  of  Fabric.  Chapter  3  turns  to  the  problem  of  referential 
security  and  presents  a  type  system  for  its  enforcement.  Chapter  4  concludes. 

The  material  in  Chapter  2  is  joint  work  with  Michael  George,  Krishnaprasad 
Vikram,  Xin  Qi,  Lucas  Waye,  and  Andrew  Myers,  and  is  adapted  from  [48].  The 
work  on  referential  security  is  joint  work  with  Andrew  Myers. 
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CHAPTER  2 


FABRIC:  SECURE  FEDERATED  COMPUTATION  AND  STORAGE 

Fabric  is  a  system  and  language  for  building  secure  federated  information 
systems.  It  is  a  decentralized  system  that  supports  secure,  shared  access  to  infor¬ 
mation  and  computation,  despite  mutual  distrust  between  cooperating  entities. 
It  has  a  high-level  programming  language  that  makes  distribution  and  persis¬ 
tence  largely  transparent  to  programmers.  Fabric  supports  both  data  shipping 
and  function  shipping:  data  and  computation  can  move  between  nodes  to  meet 
security  requirements  or  to  improve  performance.  Fabric  provides  a  rich.  Java¬ 
like  object  model.  Objects  are  labelled  with  confidentiality  and  integrity  policies 
that  are  enforced  through  a  combination  of  compile-time  and  run-time  mecha¬ 
nisms.  Optimistic,  nested  transactions  ensure  consistency  across  all  objects  and 
nodes.  A  peer-to-peer  dissemination  layer  helps  to  increase  availability  and 
to  balance  load.  Results  from  applications  built  using  Fabric  suggest  that  Fabric 
has  a  clean,  concise  programming  model,  offers  good  performance,  and  enforces 
security. 

2.1  System  architecture  overview 

Each  Fabric  node  takes  on  one  of  the  three  roles  depicted  in  Figure  2.1: 

•  Storage  nodes  (or  stores)  store  objects  persistently  and  provide  object  data 
when  requested. 

•  Worker  nodes  perform  computation,  using  both  their  own  objects  and  pos¬ 
sibly  copies  of  objects  from  storage  nodes  or  other  worker  nodes. 

•  Dissemination  nodes  provide  copies  of  objects,  giving  worker  nodes  lower 
latency  access  and  offloading  work  from  storage  nodes. 
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Figure  2.1:  Fabric  architecture 


Although  Fabric  nodes  serve  these  three  distinct  roles,  a  single  host  machine 
can  have  multiple  Fabric  nodes  on  it,  typically  colocated  in  the  same  Java  VM. 
For  example,  a  store  typically  has  a  colocated  worker,  allowing  the  store  to  in¬ 
voke  code  at  the  worker  with  low  overhead.  This  capability  is  useful,  for  ex¬ 
ample,  when  a  store  needs  to  evaluate  a  user-defined  access-control  policy  to 
decide  whether  an  object  update  is  allowed  (Section  2.3.5).  It  also  gives  the 
colocated  worker  the  ability  to  efficiently  execute  queries  against  the  store.  Sim¬ 
ilarly,  a  worker  node  can  be  colocated  with  a  dissemination  node,  making  Fabric 
more  scalable. 
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2.1.1  Security  and  assumptions 

The  design  of  Fabric  is  intended  to  allow  secure  sharing  of  computations  and 
information,  despite  the  presence  of  adversaries  that  control  some  Fabric  nodes. 
The  security  goal  of  Fabric  is  the  decentralized  security  principle:  the  security  of  a 
Fabric  user  should  not  depend  on  any  part  of  the  system  that  the  user  does  not 
trust.  (Equivalently,  the  security  of  a  user  should  only  depend  on  components 
of  the  system  that  the  user  trusts.) 

Fabric  users  are  able  to  express  complete  or  partial  trust  in  Fabric  nodes.  If 
a  user  expresses  trust  in  a  node,  the  compromise  of  that  node  might  harm  the 
security  of  that  user.  The  goal  of  Fabric  is  to  ensure  that  the  degree  of  trust 
expressed  bounds  the  degree  to  which  security  might  be  violated  from  the  per¬ 
spective  of  that  user. 

Assumptions 

The  security  of  any  system  depends  on  the  assumptions  made  about  the  threats 
it  is  designed  to  defend  against.  The  threat  assumptions  that  Fabric  makes  are 
typical  and  weak,  so  the  adversaries  considered  are  typical,  if  not  more  power¬ 
ful.  This  strengthens  the  security  assurances  of  Fabric. 

Compromised  nodes  are  assumed  to  be  malicious.  They  can  give  the  out¬ 
ward  appearance  of  a  well-behaved  node  while  behaving  maliciously.  Although 
Fabric  provides  a  programming  language  with  information-flow  security,  mali¬ 
cious  behaviour  is  not  constrained  by  the  language.  The  runtime  exposes  more 
information  than  what  is  available  at  the  language  level,  and  malicious  nodes 
can  misuse  the  information  they  receive  from  the  runtime,  such  as  object  iden¬ 
tifiers,  object  version  numbers,  and  cryptographic  keys. 

Misuse  of  information  can  include  leaking  confidential  information  or  pro- 
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viding  corrupt  information  to  other  nodes.  However,  without  the  appropriate 
cryptographic  keys,  nodes  are  assumed  to  be  unable  to  learn  encrypted  content 
or  forge  digital  signatures.  As  with  most  work  on  distributed  systems.  Fabric 
does  not  attempt  to  control  read  channels  [78],  timing  channels,  or  termination 
channels. 

Network  adversaries  are  assumed  to  be  unable  to  read  or  fabricate  network 
messages  on  trusted  channels.  This  assumption  is  justified  by  the  use  of  SSL 
for  all  store-worker  and  worker-worker  communication.  Adversaries  can  learn 
information  from  the  size,  existence,  and  timing  of  network  messages.  As  with 
most  work  on  distributed  systems.  Fabric  ignores  these  covert  channels.  Net¬ 
work  adversaries  can  also  prevent  the  delivery  of  messages.  The  availability  of 
services  written  using  Fabric  depends  on  an  assumption  that  network  messages 
are  eventually  delivered. 

2.1.2  Storage  nodes 

Storage  nodes  (stores)  persistently  store  objects  and,  on  request,  provide  copies 
of  object  data  to  worker  nodes  and  dissemination  nodes.  Access  control  pre¬ 
vents  nodes  from  obtaining  data  they  should  not  see.  The  mechanism  for  this  is 
described  briefly  here;  details  are  given  in  Section  2.3.5. 

Every  object  has  an  associated  label  describing  the  confidentiality  and  in¬ 
tegrity  requirements  of  the  object's  data  (Section  2.2.3).  When  a  worker  requests 
a  copy  of  an  object  from  a  store,  the  store  examines  the  confidentiality  part  of 
the  object's  label.  If  the  worker  is  trusted  enough  to  read  the  object,  then  the 
store  can  securely  send  the  worker  an  unencrypted  copy  of  the  object  (though 
the  network  channel  is  of  course  encrypted  by  SSL). 

This  access-control  mechanism  works  by  treating  each  Fabric  node  as  a  prin- 
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cipal  that  tracks  how  much  it  trusts  the  nodes  with  which  it  interacts.  Trust  re¬ 
lationships  are  created  by  the  delegation  mechanisms  described  in  Section  2.2.1. 

After  a  worker  fetches  an  object,  it  can  perform  computations  using  this 
cached  copy,  perhaps  modifying  its  state.  When  the  transaction  containing  these 
computations  completes,  the  worker  commits  object  updates  to  the  stores  that 
hold  objects  involved  in  the  transaction.  The  transaction  succeeds  only  if  it  is  se¬ 
rializable  with  other  transactions  at  those  stores.  As  with  object  fetch  requests, 
the  store  also  enforces  access  control  on  update  requests  based  on  the  degree  of 
trust  in  the  worker  and  the  integrity  policies  in  these  objects'  labels. 

2.1.3  Worker  nodes 

Workers  execute  Fabric  programs,  which  are  typically  written  in  the  Fabric  lan¬ 
guage.  Programs  may  incorporate  code  written  in  other  languages,  such  as  the 
Fabric  intermediate  language,  FabIL.  However,  such  code  is  considered  trusted: 
a  worker  running  such  code  must  trust  it  to  maintain  the  security  and  consis¬ 
tency  of  the  objects  it  uses.  A  worker  only  executes  trusted  code  if  it  is  stored 
on  its  local  file  system.  In  principle,  mobile  code  (code  provided  by  other  nodes) 
can  be  downloaded  and  executed  if  the  code  is  written  in  Fabric,  and  compiled 
and  signed  by  a  node  that  the  worker  trusts.  The  design  described  in  this  dis¬ 
sertation  has  been  extended  in  [3]  to  add  partial  support  for  mobile  code. 

Fabric  could,  in  principle,  provide  certifying  compilation  [58],  allowing  Fab¬ 
ric  nodes  to  check  that  compiled  code  obeys  the  Fabric  type  system — and  there¬ 
fore  that  it  correctly  enforces  access  control  and  information-flow  control — 
without  relying  on  trusting  the  compiler  or  the  node  that  runs  it.  The  design 
and  implementation  of  this  feature  are  left  to  future  work. 

Fabric  programs  modify  objects  only  inside  transactions,  which  the  Fabric 
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programming  language  exposes  to  the  programmer  as  a  simple  atomic  con¬ 
struct.  Transactions  can  be  nested,  which  is  important  for  making  code  compo¬ 
sitional.  During  transactions,  object  updates  are  logged  in  an  undo/redo  log, 
and  are  rolled  back  if  the  transaction  fails.  Such  failures  can  happen  because  of 
inconsistency,  deadlock,  or  an  application-defined  failure. 

A  Fabric  program  may  be  run  entirely  on  a  single  worker  that  issues  requests 
to  stores  (or  to  dissemination  nodes)  for  objects  that  it  needs.  This  data-shipping 
approach  makes  sense  if  the  cost  of  moving  data  is  small  compared  to  the  cost  of 
computation,  and  if  the  objects'  security  policies  permit  the  worker  to  compute 
using  them. 

When  data  shipping  does  not  make  sens e,  function  shipping  may  be  used  in¬ 
stead.  Execution  of  a  Fabric  program  may  be  distributed  across  multiple  work¬ 
ers,  by  using  remote  method  calls  to  transfer  control  to  other  workers.  Remote 
method  calls  in  Fabric  differ  from  related  mechanisms  such  as  Java  RMI  [62]  or 
CORBA  [61]: 

•  The  receiver  object  on  which  the  method  is  invoked  need  not  be  located  at 
the  remote  worker  (more  precisely,  cached  at  it)  at  the  time  of  the  call.  In 
fact,  the  receiver  object  could  be  cached  at  the  caller,  at  the  callee,  or  at 
neither.  Invocation  causes  the  callee  worker  to  cache  a  copy  of  the  receiver 
object  if  it  does  not  yet  have  a  copy. 

•  The  entire  method  call  is  executed  in  its  own  nested  transaction.  The  ef¬ 
fects  of  this  transaction  are  not  visible  to  other  code  running  on  the  remote 
node  until  the  commit  of  the  top-level  transaction  containing  the  nested 
transaction.  The  commit  protocol  (Section  2.4.3)  causes  all  workers  par¬ 
ticipating  in  the  top-level  transaction  to  commit  the  sub-transactions  that 
they  executed  as  part  of  it. 
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•  Remote  method  calls  are  subject  to  compile-time  and  run-time  access- 
control  checks.  The  caller  side  is  checked  at  compile  time  to  determine 
if  the  callee  is  trusted  enough  to  enforce  security  for  the  method;  the  callee 
checks  at  run  time  that  the  calling  node  is  trusted  enough  to  invoke  the 
method  that  is  being  called  and  to  see  the  results  of  the  method  (Sec¬ 
tion  2.2.5). 

Fabric  workers  are  multithreaded  and  can  concurrently  serve  requests  from 
other  workers.  Pessimistic  concurrency  control  (locking)  is  used  to  isolate  trans¬ 
actions  in  different  threads  from  each  other. 

One  important  use  of  remote  calls  is  to  invoke  an  operation  on  a  worker 
colocated  with  a  store.  Since  a  colocated  worker  has  low-cost  access  to  persis¬ 
tent  objects,  this  can  improve  performance  substantially.  This  idea  is  analogous 
to  a  conventional  application  issuing  a  database  query  for  low-cost  access  to 
persistent  data.  In  Fabric,  a  remote  call  to  a  worker  that  is  colocated  with  a  store 
can  be  used  to  achieve  this  goal,  with  two  advantages  compared  to  database 
queries:  the  worker  can  run  arbitrary  Fabric  code,  and  information-flow  secu¬ 
rity  is  enforced. 

2.1.4  Dissemination  nodes 

Objects  are  cached  at  dissemination  nodes,  to  prevent  stores  with  popular  ob¬ 
jects  from  becoming  bottlenecks.  Rather  than  requesting  objects  from  remote  or 
heavily  loaded  stores,  workers  can  request  objects  from  dissemination  nodes. 
Objects  are  disseminated  at  the  granularity  of  object  groups,  thereby  amortizing 
the  costs  associated  with  fetching  remote  objects  (Section  2.3.2). 

On  request,  stores  provide  object  data  in  encrypted  form  to  dissemination 
nodes.  Receiving  encrypted  objects  does  not  require  as  much  trust,  because  the 
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fields  of  the  object  are  not  visible  without  the  object's  encryption  key,  which 
dissemination  nodes  do  not  possess  in  general. 

Fabric  has  no  prescribed  dissemination  layer;  workers  may  use  any  dissem¬ 
ination  nodes  they  choose,  and  dissemination  nodes  may  use  whatever  mecha¬ 
nism  they  want  to  find  and  provide  objects.  In  the  dissemination  layer  provided 
with  the  current  Fabric  implementation,  the  dissemination  nodes  form  a  peer- 
to-peer  content  distribution  network  based  on  FreePastry  [69].  However,  other 
dissemination  architectures  can  be  substituted  if  the  interface  to  workers  and 
stores  remains  the  same. 

To  help  keep  caches  up  to  date,  workers  and  dissemination  nodes  are  im¬ 
plicitly  subscribed  to  any  object  group  they  read  from  a  store.  When  any  object 
in  the  group  is  updated,  the  store  sends  the  updated  group  to  its  subscribers. 
The  dissemination  layer  is  responsible  for  relaying  group  updates  to  workers 
that  have  read  them.  A  transaction  that  has  read  out-of-date  data  can  then  be 
aborted  and  retried  by  its  worker  on  receipt  of  the  updated  group.  Updated 
groups  are  delivered  to  their  subscribers  on  a  best-effort  basis. 

2.2  The  Fabric  language 

Fabric  offers  a  high-level  language  for  building  distributed  programs  with 
information-flow  security.  It  is  an  extension  to  the  Jit  programming  lan¬ 
guage  [53,56],  which  also  enforces  secure  information  flow  and  has  been  used  to 
build  significant  systems  (e.g.,  [12,14,16,36]).  Fabric  adds  three  major  features 
to  Jit: 

•  Nested  transactions  ensure  that  computations  observe  and  update  objects 
consistently,  and  provide  clean  recovery  from  failures. 
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•  Remote  method  calls  (remote  procedure  calls  to  methods)  allow  dis¬ 
tributed  computations  that  span  multiple  workers. 

•  Remote  objects  are  accessed  transparently,  as  if  they  are  local  objects. 

While  these  features  may  seem  unusual,  they  are  not  new.1  The  contribution 
of  Fabric,  however,  is  in  combining  these  features  with  information-flow  secu¬ 
rity.  This  requires  new  mechanisms  to  ensure  that,  for  example,  transactions  do 
not  leak  confidential  information,  and  remote  calls  are  properly  authorized.  To 
support  compile-time  and  run-time  enforcement  of  secure  distributed  compu¬ 
tation,  Fabric  also  adds  a  new  trust  ordering  on  information-flow  labels. 

2.2.1  Principals 

Principals  in  Fabric  represent  entities  with  authority,  privilege,  or  trust.  This 
includes  users,  roles,  groups,  organizations,  privileges,  and  Fabric  nodes.  As  in 
Jif  [53],  they  are  manifested  in  the  Fabric  programming  language  as  objects  with 
the  built-in  type  principal. 

Expressing  trust:  acts-for 

Trust  relationships  between  principals  are  represented  by  the  acts-for  rela¬ 
tion  [55].  If  a  principal  p  acts  for  principal  q,  any  action  by  principal  p  can  be 
considered  to  come  from  principal  q  as  well.  These  actions  include  statements 
made  by  principal  p.  Thus,  this  acts-for  relationship  means  q  trusts  p  completely. 
We  write  this  relationship  more  compactly  as  p  ^  q.  The  acts-for  relation  ^  is  a 
pre-order  (transitive  and  reflexive). 

There  is  a  most-trusted  top  principal  T  that  acts  for  all  other  principals,  and  a 
least-trusted  bottom  principal  l  that  all  principals  act  for.  The  operators  a  and  v 
1  Argus  [47]  has  the  first  two,  for  example. 


19 


can  be  used  to  form  conjunctions  and  disjunctions  of  principals.  The  conjunctive 
principal  p  a  q  represents  the  joint  authority  of  p  and  q,  and  acts  for  them  both: 
p  a  q  z  p  and  p  a  q  z  q.  The  disjunctive  principal  p  v  q  represents  the  disjoint 
authority  of  p  and  q.  Both  p  and  q  act  for  the  disjunctive  principal  p  v  q  (i.e., 
p^  pv  q  and  q^pv  q).  The  conjunctive  and  disjunctive  principal  operators  are 
both  commutative  and  associative. 

Object  representation  of  principals 

The  Fabric  model  of  principals  is  similar  to  the  model  in  Jif  3.0  [14], 
Principals  are  represented  as  objects  that  inherit  from  the  abstract  class 
fabric .  lang.  security .  Principal.2  Instances  of  any  subclass  can  be  used  as 
principals.  Like  other  Fabric  objects,  principals  can  be  distributed  and  persis¬ 
tent. 

Principals  control  their  acts-for  relationships  by  implementing  a  method 
p .  delegatesTo  (q),  which  tests  whether  q  directly  acts  for  p.  This  allows  a 
principal  to  say  who  can  directly  act  for  it.  The  Fabric  runtime  system  at  each 
worker  node  automatically  computes  and  stores  the  transitive  closure  of  these 
direct  acts-for  relationships  in  a  security  cache  (Section  2.3.8).  The  runtime  sys¬ 
tem  also  exposes  operations  for  notifying  it  that  acts-for  relationships  have  been 
added,  which  causes  the  acts-for  cache  to  be  updated  conservatively  to  remove 
any  information  that  might  be  stale.  In  general,  worker  nodes  may  have  differ¬ 
ent  partial  views  of  the  acts-for  relation.  The  monotonicity  of  the  label  system 
ensures  that  security  decisions  based  on  these  partial  views  are  sound:  any  acts- 
for  relationships  that  a  worker  has  not  observed  would  only  make  its  security 
decisions  more  permissive  [55]. 

instances  of  fabric  .  lang .  security .  Principal  can  be  implicitly  cast  to  the  built-in  type 
principal,  and  vice  versa. 
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The  Fabric  runtime  also  supports  the  revocation  of  acts-for  relationships. 
Supporting  revocation  involves  a  trade-off  between  security  and  performance 
(or  availability),  a  challenge  commonly  encountered  in  the  design  of  public-key 
infrastructures.  To  ensure  sound  authorization  decisions,  revocation  notifica¬ 
tions  must  rapidly  propagate  to  all  who  might  rely  on  the  revoked  authority. 
However,  rapid  propagation  comes  at  a  performance  cost,  and  the  propagation 
mechanism  itself  can  be  vulnerable  to  denial-of-service  attack. 

Fabric  does  not  guarantee  immediate  notification  of  revoked  acts-for  rela¬ 
tionships.  A  worker  with  a  cached  copy  of  principal  p  will  not  see  a  revoca¬ 
tion  of  "q  acts  for  p"  until  it  receives  an  updated  copy  of  p.  This  can  happen 
through  object  subscriptions  (Section  2.3.10).  However,  the  subscription  mech¬ 
anism  only  operates  on  a  best-effort  basis.  In  the  worst  case,  the  worker  will  not 
receive  the  updated  p  until  a  transaction  attempts  to  commit,  after  having  ob¬ 
served  the  revoked  acts-for  relationship.  As  with  any  transaction  that  observes 
stale  data,  the  transaction  is  rolled  back  and  retried  with  the  new  version  of  p. 

Node  principals 

Principals  can  use  acts-for  relationships  to  specify  the  degree  to  which  they 
trust  Fabric  nodes.  Fabric  nodes  are  represented  as  first-class  objects  in  Fab¬ 
ric  that  can  be  implicitly  converted  to  principal  objects  that  represent  the  node. 
For  example,  a  storage  node  might  be  represented  as  a  variable  s  of  type 
fabric. worker. Store.  The  test  s  actsfor  p  would  then  test  whether  a  prin¬ 
cipal  p  trusts  s.  This  would  always  be  the  case  if  the  principal  p  were  stored  at 
store  s. 

Fabric  has  a  built-in  way  to  authenticate  worker  nodes  as  corresponding 
to  their  Fabric  worker-node  objects.  This  is  accomplished  using  X.509  certifi- 
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cates  [37]  that  include  the  node's  public  key  and  the  oid  of  its  principal  object 
(Section  2.3.4).  Whether  the  certificates  of  a  given  certificate  authority  are  ac¬ 
cepted  is  decided  by  the  Fabric  node  receiving  them. 

Authority 

When  running.  Fabric  code  can  possess  the  authority  of  a  principal,  and  may 
carry  out  actions  permitted  to  that  principal,  such  as  declassifying  information 
to  lower  its  confidentiality,  or  endorsing  information  to  raise  its  integrity.  As  in 
Jif,  code  can  obtain  the  authority  of  a  principal  p  in  two  ways.  In  both  cases,  the 
code  must  be  compiled  and  signed  by  a  node  that  acts  for  p. 

First,  a  class  can  declare  it  has  authority  by  using  a  clause  authority  (p). 
A  method  of  the  class  can  then  claim  this  authority  with  a  clause  where 
authority  (p).  Second,  authority  can  be  delegated  via  a  method  call,  if  the 
method  being  called  is  annotated  with  a  clause  where  caller (p).  Such  meth¬ 
ods  with  delegated  authority  can  only  be  called  from  code  that  possesses  the 
authority  of  p.  While  this  model  of  delegating  authority  has  similarities  to  Java 
stack  inspection  [76],  it  differs  in  that  authority  is  statically  checked  except  at  re¬ 
mote  method  calls,  where  the  receiver  checks  that  the  calling  node  is  sufficiently 
trusted  (Section  2.2.5). 

Principals  express  their  security  concerns  by  labelling  information  with 
information-flow  policies. 

2.2.2  Labels 

Information  security  in  Fabric  is  provided  by  information-flow  control.  All 
information  is  labelled  with  information-flow  policies.  These  labels  are  prop¬ 
agated  through  computation  using  compile-time  type  checking,  but  run-time 
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checks  are  used  for  dynamic  policies  and  to  deal  with  untrusted  nodes.  There 
are  two  kinds  of  policies:  confidentiality  policies  and  integrity  policies.  While 
these  policies  are  similar  to  those  in  Jit,  they  have  a  subtly  different  interpreta¬ 
tion  in  Fabric  because  of  the  federated  nature  of  the  system. 

Confidentiality  and  integrity  policies 

Confidentiality  policies  and  integrity  policies  are  built  up  from  reader  policies 
and  writer  policies,  respectively.  These,  in  turn,  have  two  components:  owners 
and  subjects.  The  owner  of  a  policy  specifies  the  principal  whose  information  is 
being  governed  by  the  policy.  The  subject  specifies  the  principal  who  can  act  on 
(learn  or  affect)  that  information. 

The  reader  policy  alice-*bob,  for  example,  says  that  principal  alice  owns  the 
policy  and  that  she  permits  principal  bob  to  indirectly  learn  about  (or  directly 
read)  information  that  is  labelled  with  the  policy.  If  bob  is  trustworthy,  however, 
he  will  not  leak  this  information  to  untrusted  third  parties,  because  the  informa¬ 
tion  is  not  his  to  disclose.  Therefore,  alice  is  trusting  bob  to  not  inappropriately 
leak  information  labelled  with  the  policy  alice^bob. 

Similarly,  the  writer  policy  alice^bob  means  that  alice  permits  bob  to  indi¬ 
rectly  affect  (or  directly  modify)  the  labelled  information;  she  is  trusting  bob  to 
not  inappropriately  taint  that  information  with  data  from  untrusted  sources. 

Owners  are  implicitly  subjects  in  their  own  policies.  A  principal  is  a  reader 
for  a  reader  policy  o  r  if  the  principal  acts  for  o  v  r.  A  principal  is  a  writer  for 
a  writer  policy  o  <-  w  if  the  principal  acts  for  ovw.  So,  the  policy  alice-^-bob 
is  equivalent  to  alice^bobvalice,  also  written  as  alice->bob,  alice.  Similarly, 
alice^bob  is  equivalent  to  alice^bobvalice,  also  written  alice^bob, alice. 

A  confidentiality  policy  is  a  set  of  reader  policies,  all  of  which  are  enforced 
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simultaneously;  a  principal  can  learn  about  a  value  only  when  it  is  a  reader  for 
all  reader  policies  in  the  value's  confidentiality  policy  An  integrity  policy  is  a  set 
of  writer  policies;  a  principal  can  affect  a  value  only  when  it  is  a  writer  for  any 
writer  policy  in  the  value's  integrity  policy 

A  label  is  simply  a  set  of  confidentiality  and  integrity  policies,  such  as 
{alice-+bob;bob-^-alice}.  These  decentralized  labels  [55]  keep  track  of  whose  se¬ 
curity  is  being  enforced,  which  is  useful  for  Fabric,  where  principals  need  to 
cooperate  despite  mutual  distrust. 

Declassification  and  endorsement 

Information-flow  security  policies  are  expressed  in  terms  of  principals,  which  is 
important  because  it  enables  the  integration  of  access  control  and  information- 
flow  control.  A  key  use  of  this  integration  is  for  authorizing  the  downgrading 
of  information-flow  policies  through  declassification  (for  confidentiality)  and 
endorsement  (for  integrity). 

For  example,  on  a  worker  w  trusted  by  alice  (i.e.,  w  ^  alice),  information 
labelled  with  the  policy  alice^-bob  can  be  explicitly  declassified  by  code  that  is 
running  with  the  authority  of  alice,  removing  that  policy  from  the  label. 

Information-flow  ordering 

The  Fabric  compiler  checks  information  flows  at  compile  time  to  ensure  that 
both  explicit  and  implicit  [25]  information  flows  are  secure.  To  do  this,  it  uses 
Jif's  information-flow  ordering  E,  which  captures  when  information  flow  is  secure: 
if  Li  E  L2r  then  information  labelled  L1  can  securely  flow  to  (or  be  relabelled 
with)  L2.  The  relationship  Lx  E  L2  can  be  read  “Lx  flows  to  L2" . 
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(a)  Reader  policies  (b)  Writer  policies 

Figure  2.2:  Orderings  on  reader  and  writer  policies 

Reader  policies  Figure  2.2a  depicts  how  the  acts-for  relation  and  information- 
flow  ordering  relate  for  reader  policies.  Information  flows  upwards  in  the  di¬ 
agram.  The  information-flow  ordering  is  covariant  in  both  the  owner  and  the 
subject.  For  example,  we  have  {alice  -»•  bob}  E  {charlie  ->  dora}  exactly  when 
Charlie  ^  alice  (owner  covariance)  and  dora  ^  bob  v  alice3  (subject  covari¬ 
ance). 

As  a  value  flows  through  a  program,  the  set  of  principals  that  can  declassify 
or  read  should  only  get  smaller  (unless  the  value  is  declassified  or  the  principal 
hierarchy  changes).  Owner  covariance  is  important  because  it  ensures  control 
of  declassification  is  not  lost.  The  new  owner  acts  for  the  old  owner,  so  any 
principal  having  the  authority  to  declassify  under  the  new  policy  also  had  that 
authority  under  the  old  policy.  Subject  covariance  ensures  information  is  not 
leaked;  the  new  subject  acts  for  the  old  subject,  so  any  principal  able  to  read 
under  the  new  policy  also  had  that  ability  under  the  old  policy. 

Therefore,  the  least  reader  policy,  at  the  bottom  of  Figure  2.2a,  describes  in¬ 
formation  that  is  completely  public:  {i  -»•  i}.  The  greatest  reader  policy,  at  the 
top  of  the  figure,  describes  information  that  is  completely  secret:  {t  -»•  t}. 

3The  subject  covariance  condition  is  technically  dora  v  charlie  5=  bob  v  alice,  but  the  dis¬ 
junction  with  dora  is  omitted  because  it  is  satisfied  by  owner  covariance. 
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Writer  policies  Integrity  works  the  opposite  way,  because  integrity  policies 
allow  flow  from  trusted  sources  to  untrusted  recipients.  Integrity  policies  reflect 
the  set  of  principals  that  could  have  endorsed  or  modified  a  value.  To  be  safe, 
this  should  only  get  larger  (unless  the  value  is  further  endorsed  or  the  principal 
hierarchy  changes). 

Figure  2.2b  shows  how  the  acts-for  relation  and  information-flow  ordering 
relate  for  writer  policies.  Information  flows  downwards  in  the  diagram.  The 
information-flow  ordering  is  contravariant  in  both  the  owner  and  the  subject. 
The  relationship  {alice  •«-  bob}  E  {charlie  •«-  dora}  holds  exactly  when  we 
have  alice  ^  charlie  (owner  contravariance)  and  bob  ^  doravcharlie4  (subject 
contravariance). 

Owner  contravariance  ensures  those  principals  who  have  endorsed  the  la¬ 
belled  information  are  reflected  in  the  new  owner.  The  old  owner  acts  for  the 
new  owner,  so  any  principal  who  may  have  endorsed  to  the  old  policy  could 
also  have  endorsed  to  the  new  policy.  Subject  contravariance  ensures  those 
principals  who  have  affected  the  labelled  information  are  reflected  in  the  new 
subject.  The  old  subject  acts  for  the  new  subject,  so  any  principal  able  to  modify 
under  the  old  policy  also  has  that  ability  under  the  new  policy.5 

Therefore,  the  least  writer  policy,  at  the  top  of  Figure  2.2b,  describes  infor¬ 
mation  that  is  completely  uncorrupted:  {t  •«-  t}.  The  greatest  writer  policy, 
at  the  bottom  of  the  figure,  describes  information  that  is  completely  corrupted: 
{l  •«-  l}.  While  this  ordering  is  opposite  of  the  intuitive  ordering  for  integrity, 
we  still  refer  to  information  labelled  {l  <-  1}  as  having  low  integrity,  and  infor¬ 
mation  labelled  {t  •«-  t}  as  having  high  integrity.  Similarly,  phrases  such  as  lozver 
integrity  and  higher  integrity  refer  to  the  intuitive  ordering. 

4The  subject  contravariance  condition  is  technically  bob  v  alice  5=  dora  v  charlie,  but  the 
disjunction  with  alice  is  omitted  because  it  is  satisfied  by  owner  contravariance. 

5See  [54]  for  more  justification  of  these  rules. 
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secret,  corruptible 


Figure  2.3:  Orderings  on  the  space  of  labels 


Labels  Information  labelled  L1  can  flow  to  another  label  L2  if  every  reader 
policy  in  L\  can  flow  to  every  reader  policy  in  L2,  and  every  writer  policy  in  L  \ 
can  flow  to  every  writer  policy  in  L2. 

Figure  2.3  depicts  the  information-flow  ordering  on  labels.6  Information 
flows  upwards  in  the  diagram.  The  least  label,  at  the  bottom  of  the  figure,  de¬ 
scribes  information  that  can  flow  anywhere,  because  it  is  public  and  completely 
uncorrupted:  {l  -»•  1;  T  •«-  t}.  The  greatest  label,  at  the  top  of  the  figure,  de¬ 
scribes  information  that  can  flow  nowhere,  because  it  is  completely  secret  and 
completely  corrupted:  {t  -»•  T;  1  •«-  l}. 

Formally,  the  information-flow  ordering  is  a  pre-order  over  the  set  of  labels. 
The  equivalence  classes  of  labels  form  a  bounded  join-semilattice,  where  lifted 
set  unions  are  joins.7  The  equivalence  classes  of  confidentiality  policies  form  a 
sub-semilattice,  as  do  the  equivalence  classes  of  integrity  policies. 

6Whereas  Figure  2.2  shows  each  of  the  spaces  of  confidentiality  and  integrity  policies  in  two 
dimensions,  in  Figure  2.3  they  are  each  collapsed  to  one  dimension  for  clarity. 

7  A  meet  operator  can  be  defined  as  well  to  obtain  a  full  lattice.  See  [54]  for  details. 
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1  int  {alice^bob}  x; 

2  int  {alice^bob,  Charlie}  y; 

3  x  =  y;  //  OK:  bob  ^  (bob  v  Charlie) 

4  y  =  x;  //  Invalid 

5  if  (charlie  actsfor  bob)  { 

6  y  =  x;  //  OK:  charlie  ^  bob,  so  (bob  v  charlie)  ^  bob 

7  } 

Figure  2.4:  Code  example  illustrating  information-flow  rules 

Example  The  code  in  Figure  2.4  illustrates  these  rules.  The  assignment  from 
y  to  x  (line  3)  is  secure  because  the  information  in  y  can  be  learned  by  fewer 
readers  (only  bob  rather  than  both  bob  and  charlie).  The  assignment  from  x 
to  y  (line  4)  is  rejected  by  the  compiler,  because  it  permits  charlie  to  read  the 
information.  However,  the  second  assignment  from  x  to  y  (line  6)  is  allowed 
because  it  occurs  in  a  context  where  charlie  is  known  to  act  for  bob,  and  can 
therefore  already  read  any  information  that  bob  can. 

Trust  ordering 

Fabric  extends  the  DLM  by  defining  a  second  ordering  on  labels,  the  trust  or¬ 
dering,  which  is  useful  for  reasoning  about  the  enforcement  of  policies  by  a  par¬ 
tially  trusted  platform.  A  label  Lx  may  require  at  least  as  much  trust  as  a  label 
L2,  which  we  write  as  L  \  z  L>  by  analogy  with  the  trust  ordering  on  princi¬ 
pals.  If  Li  requires  at  least  as  much  trust  as  L2,  then  any  platform  trusted  to 
enforce  Li  is  also  trusted  to  enforce  L2.  This  happens  when  Li  describes  confi¬ 
dentiality  and  integrity  policies  that  are  at  least  as  strong  as  those  in  L2;  unlike 
in  the  information-flow  ordering,  integrity  is  not  opposite  to  confidentiality  in 
the  trust  ordering. 

Therefore,  both  confidentiality  and  integrity  use  the  same  rules  in  the  trust 
ordering.  As  shown  in  Figure  2.2,  they  are  covariant  in  both  the  owner  and  the 
subject;  required  trust  increases  upwards  in  the  diagram.  Both  {alice  bob}  ^ 
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{charlie  -»•  dora}  and  {alice  ■*-  bob}  ^  {charlie  ■*-  dora}  are  true  exactly  when 
alice  £  charlie  and  bob  ^  dora  v  charlie. 

Figure  2.3  depicts  the  trust  ordering  on  labels,  and  how  it  relates  to  the 
information-flow  ordering.  Required  trust  increases  rightwards  in  the  diagram. 
In  the  trust  ordering,  the  least  label  (leftmost  in  the  figure)  describes  informa¬ 
tion  that  requires  no  trust  to  enforce  its  security,  because  it  is  completely  public 
and  completely  corrupted:  {l  -»•  1;  1  <-  l}.  The  greatest  label  (rightmost  in  the 
figure)  is  for  information  that  is  completely  secret  and  completely  uncorrupted: 
{T^T;T<-T}. 

2.2.3  Object  labels 

Like  in  Jif,  each  field  in  a  Fabric  object  can  have  a  different  label  that  the  compiler 
uses  to  control  the  flow  of  the  information  contained  in  that  field.  For  efficiency, 
these  field  labels  are  summarized  into  a  single  object  label  that  governs  the  use 
of  information  in  that  object  at  run  time.  This  label  determines  which  storage 
nodes  can  store  the  object  persistently  and  which  worker  nodes  can  cache  and 
compute  directly  on  the  object.  It  also  controls  which  object  groups  an  object 
may  be  part  of  and  which  key  objects  may  be  used  to  encrypt  it  for  dissemina¬ 
tion. 

An  object  with  label  La  may  be  stored  securely  on  a  store  n  if  the  store  is 
trusted  to  enforce  L0.  Recalling  that  n  can  be  used  as  a  principal,  this  condition 
is  captured  formally  using  the  trust  ordering  on  labels: 

{t  -»■  n;  T  •«-  n}  £  L0  (2.1) 

To  see  this,  suppose  L0  has  a  confidentiality  policy  {p  q},  which  is  equivalent 
to  {p  -»  p  v  q}.  Condition  2.1  holds  exactly  when  T  Z  p  (always  true)  and  n^pvq, 


29 


which  implies  n  p  or  n  £  q — either  p  must  trust  n,  or  p  must  believe  that  n 
is  allowed  to  read  things  that  q  is  allowed  to  read.  Conversely,  if  La  has  an 
integrity  policy  {p  <-  q),  we  require  the  same  condition,  n  £  p  v  q — either  p  trusts 
n,  or  p  believes  that  n  is  allowed  to  affect  things  that  q  is.  Therefore  we  can  write 
L(n )  to  denote  the  label  corresponding  to  node  n,  which  is  {t  -»  n;  T  •«-  n),  and 
express  condition  2.1  simply  as  L(n )  ?=  La. 

The  object  label  is  defined  as  the  trust-ordering  join  of  the  object's  field  labels. 
This  is  a  safe  but  conservative  summary  that  can  prohibit  some  secure  flows 
at  run  time;  however,  per-field  precision  can  be  recovered  by  introducing  an 
additional  level  of  indirection  in  the  object  graph. 

Fabric  classes  may  be  parameterized  with  respect  to  labels  or  principals,  so 
different  instances  of  the  same  class  may  have  different  labels.  This  feature,  in¬ 
herited  from  Jif,  allows  implementation  of  reusable  classes,  such  as  data  struc¬ 
tures  that  can  hold  information  with  different  labels. 

By  design.  Fabric  does  not  provide  persistence  by  reachability  [4]  because  it 
can  lead  to  unintended  persistence.  Therefore,  constructors  are  annotated  to 
indicate  the  store  on  which  the  newly  created  object  should  be  made  persistent. 
The  call  new  C@s  (...)  creates  a  new  object  of  class  C  on  the  store  identified 
by  the  variable  s.  Except  for  reserving  oids,8  no  communication  with  the  store 
is  needed  until  commit.  If  the  store  of  an  object  is  omitted,  the  new  object  is 
created  at  the  same  store  as  the  object  whose  method  calls  new.  Objects  may 
have  non-final  fields  that  are  marked  transient.  These  transient  fields  are  not 
saved  persistently,  which  is  similar  to  their  treatment  by  Java  serialization  [32], 

8This  is  done  in  batch  ahead  of  time,  so  the  communication  cost  for  this  can  be  amortized 
across  many  objects. 
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2.2.4  Tracking  implicit  flows 

Information  can  be  conveyed  by  program  control  flow.  If  not  controlled,  these 
implicit  flows  can  allow  adversaries  to  learn  about  confidential  information  from 
control  flow,  or  to  influence  high-integrity  information  by  affecting  control  flow. 

Fabric  controls  implicit  flows  through  the  program-counter  label,  written  pc, 
which  captures  the  confidentiality  and  integrity  of  control  flow.  The  program- 
counter  label  works  by  constraining  side  effects;  to  assign  to  a  variable  x  with 
label  Lx,  Fabric  requires  pc  E  Lx.  If  this  condition  does  not  hold,  either  informa¬ 
tion  with  a  stronger  confidentiality  policy  could  leak  into  x,  or  information  with 
a  weaker  integrity  policy  could  affect  x. 

Implicit  flows  cross  method-call  boundaries,  both  local  and  remote.  To  track 
these  flows,  object  methods  are  annotated  with  a  begin  label  that  constrains  the 
program-counter  label  of  the  caller,  as  well  as  the  effects  of  the  method.  The 
pc  of  the  caller  must  flow  to  the  begin  label,  which  in  turn  must  flow  to  the 
label  of  any  variables  assigned  by  the  method.  This  ensures  that  the  caller's  pc 
can  flow  to  the  method's  assignments.  Implicit  flows  via  exceptions  and  other 
control-flow  mechanisms  are  also  tracked  [53]. 

Because  implicit  flows  are  controlled,  untrusted  code  and  untrusted  data 
cannot  affect  high-integrity  control  flow  unless  an  explicit  downgrading  action 
is  taken,  using  the  authority  of  the  principals  whose  integrity  policies  are  af¬ 
fected.  Furthermore,  because  Fabric  enforces  robustness  [13],  untrusted  code 
and  untrusted  data  cannot  affect  information  release.  Thus,  Fabric  provides 
general  protection  against  a  wide  range  of  security  vulnerabilities. 
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1  void  ral{alice<-}  ()  { 

2  Worker  rw  =  findWorker ("bob . example . org") ; 

3  if  (rw  actsfor  bob)  { 

4  intfalice^bob]-  data  =  1; 

5  int{alice->}  y  =  m2@rw(data) ; 

6  } 

7  } 

8 

9  intfalice^bob}-  m2{alice<-}-  (intfalice^bob}  x)  { 

10  return  x+1; 

li } 


Figure  2.5:  A  remote  call  in  Fabric 


Figure  2.6:  Compile-time  and  run-time  checks  for  remote  calls 


2.2.5  Remote  calls 

Distributed  control  transfers  are  always  explicit  in  Fabric.  Fabric  introduces  the 
syntax  o  .m@w(a! ,  ,a.n)  to  signify  a  remote  method  call  to  the  worker  node 

identified  by  variable  w,  invoking  the  method  m  of  object  o.  If  the  syntax  @w  is 
omitted,  the  method  call  is  always  local,  even  if  the  object  o  is  not  cached  on  the 
current  node  (in  which  case,  the  object  will  be  fetched  and  the  method  invoked 
locally).  Figure  2.5  shows  example  code  in  which,  at  line  5,  a  method  ml  calls 
a  method  m2  on  the  same  object,  but  at  a  remote  worker  that  is  dynamically 
looked  up  using  its  hostname. 

Remote  method  calls  are  subject  to  both  compile-time  and  run-time  check¬ 
ing.  Figure  2.6  illustrates  the  checks  made.  The  compiler  permits  a  call  to  a  re- 
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mote  method  only  if  it  can  statically  determine  that  the  call  is  secure,  as  shown 
on  the  left  side  of  the  figure.  Information  sent  to  a  receiver  worker  rw  can  be 
read  by  rw,  so  all  information  sent  in  the  call  (the  object,  the  arguments,  and  the 
implicit  flow)  must  have  labels  Ls  where  Ls  E  {t  -»•  rw}.  For  example,  in  Fig¬ 
ure  2.5,  the  variable  data,  with  label  {alice  -*  bob},  can  be  passed  to  method  m2 
only  because  the  call  happens  in  a  context  where  it  is  known  that  rw  £  bob,  and 
hence  {alice  ->  bob}  E  {t  ->  rw}. 

Information  received  from  rw  can  be  affected  by  it,  so  by  a  similar  argument, 
all  information  returned  from  the  call  must  have  labels  Lr  where  {t  •«-  rw}  E  Lr. 

The  recipient  of  a  remote  method  call  has  no  a  priori  knowledge  that  the 
caller  is  to  be  trusted,  so  run-time  checking  is  needed.  When  a  call  occurs  from 
caller  worker  cw  to  receiver  worker  rw,  the  receiver  checks  all  information  sent 
or  received  at  label  L  (including  implicit  flows),  to  ensure  that  {t  <-  cw}  £  L.  For 
example,  in  Figure  2.5,  the  method  m2  has  a  begin  label  that  requires  the  integrity 
{alice  •«-}.  Therefore,  when  bob .  example  .  org  receives  the  remote  call  to  m2,  it 
will  check  that  the  calling  worker  has  the  authority  of  alice,  thereby  ensuring 
{t  •«-  cw}  5:  {alice  «-}.  The  compiler  makes  additional  checks  to  ensure  that 
these  run-time  checks  themselves  do  not  leak  information. 

2.2.6  Transactions 

All  changes  to  Fabric  objects  take  place  inside  transactions,  to  provide  concur¬ 
rency  control  and  ensure  consistency  of  reads  and  writes.  A  transaction  is  in¬ 
dicated  in  Fabric  code  by  the  construct  atomic  {  S  },  where  the  transaction 
body  S  is  a  sequence  of  statements.  The  semantics  is  that  the  statement  S  is 
executed  atomically  and  in  isolation  from  all  other  computations  in  Fabric.  In 
other  words.  Fabric  enforces  serializability  of  transactions. 
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Accesses  to  mutable  fields  of  Fabric  objects  are  not  permitted  outside  trans¬ 
actions.  Reads  from  objects  that  occur  outside  transactions  are  each  treated  as 
its  own  transaction. 

If  a  transaction  body  throws  an  exception,  the  transaction  is  considered  to 
have  failed,  and  is  aborted.  If  the  body  terminates  successfully,  its  side  effects 
become  visible  outside  its  transaction.  Failure  due  to  conflict  with  other  transac¬ 
tions  causes  the  atomic  block  to  be  retried  automatically  with  exponential  back¬ 
off.  If  the  maximum  number  of  retries  is  exceeded,  the  transaction  is  terminated. 

Transactions  may  also  be  explicitly  retried  or  aborted  by  the  programmer.  A 
retry  statement  rolls  back  the  enclosing  atomic  block  and  restarts  it  from  the 
beginning;  an  abort  statement  also  rolls  back  the  enclosing  atomic  block,  but 
results  in  throwing  the  exception  UserAbortException.  Aborting  a  transaction 
creates  an  implicit  flow;  therefore.  Fabric  statically  enforces  that  the  pc  of  the 
abort  is  lower  than  or  equal  to  the  pc  of  the  atomic  block:  pcabort  E  ^catomic 
Exceptions  generated  by  the  transaction  body  are  checked  similarly. 

Atomic  blocks  may  be  used  even  during  a  transaction,  because  Fabric  al¬ 
lows  nested  transactions.  This  allows  programmers  to  enforce  atomicity  with¬ 
out  worrying  about  whether  their  abstractions  are  at  "top  level"  or  not.  Atomic 
blocks  can  also  be  used  as  a  way  to  cleanly  recover  from  application-defined 
failures,  via  abort. 

Multi-worker  computations  (i.e.,  computations  with  remote  calls)  take  place 
in  atomic,  isolated  transactions  that  span  all  the  workers  involved.  The  Fabric 
runtime  system  ensures  that  when  multiple  workers  use  the  same  object  within 
a  transaction,  updates  to  the  object  are  propagated  between  them  as  necessary 
(Section  2.4.1). 

Transactions  are  single- threaded;  new  threads  cannot  be  started  inside  a 
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transaction,  though  a  worker  may  run  multiple  transactions  concurrently.  This 
choice  was  made  largely  to  simplify  the  implementation,  though  it  maps  well 
onto  many  of  the  applications  for  which  Fabric  is  intended. 

Fabric  uses  a  mix  of  optimistic  and  pessimistic  concurrency  control.  In  the 
distributed  setting,  it  is  optimistic,  because  worker  nodes  compute  on  cached 
copies  of  objects  that  may  be  out  of  date,  and  a  distributed  two-phase  com¬ 
mit  protocol  [31]  ensures  consistency  at  commit  time.  However,  to  coordinate 
threads  running  on  the  same  worker.  Fabric  uses  pessimistic  concurrency  con¬ 
trol,  in  which  threads  acquire  locks  on  objects. 

Though  distributed  deadlocks  may  occur  in  Fabric,  there  are  standard  tech¬ 
niques  (e.g,  edge  chasing  [11])  for  detecting  and  avoiding  them  in  a  non- 
federated  context.  We  leave  to  future  work  the  design  and  implementation  of  a 
secure  deadlock-detection  mechanism  for  a  federated  system  like  Fabric. 

2.2.7  Java  interoperability 

Fabric  programs  can  be  written  using  a  mixture  of  Java,  Fabric,  and  FabIL  (the 
Fabric  intermediate  language).  FabIL  is  an  extension  to  Java  that  supports  trans¬ 
actions  and  remote  calls,  but  not  information-flow  labels  or  static  information- 
flow  control.  More  concretely,  FabIL  supports  the  atomic  construct  and  gives 
the  ability  to  invoke  methods  and  constructors  with  annotations  @w  and  @s  re¬ 
spectively.  Transaction  management  is  performed  on  Fabric  and  FabIL  objects 
but  not  on  Java  objects,  so  the  effects  of  failed  transactions  on  Java  objects  are 
not  rolled  back. 

FabIL  and  Java  code  is  considered  trusted,  and  workers  only  execute  trusted 
code  that  is  stored  on  their  local  file  system.  Therefore,  the  use  of  FabIL  or 
Java  code  in  Fabric  programs  offers  lower  assurance  to  principals  who  trust  the 
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nodes  running  this  code.  This  is  compatible  with  the  decentralized  security 
principle,  because  the  effects  of  trusted  code  is  confined  to  these  principals. 

FabIL  can  be  convenient  for  code  whose  security  properties  are  not  accu¬ 
rately  captured  by  static  information-flow  analysis,  making  the  labels  of  the  full 
Fabric  language  counterproductive.  An  example  is  code  implementing  cryptog¬ 
raphy. 


2.3  The  Fabric  runtime  system 

This  section  describes  the  features  of  the  Fabric  runtime  system  for  supporting 
single-worker  transactions.  Section  2.4  extends  these  features  with  support  for 
multi-worker  transactions  and  remote  calls. 

2.3.1  Object  model 

Information  in  Fabric  is  stored  in  objects.  Fabric  objects  are  similar  to  Java  ob¬ 
jects;  they  are  typically  small  and  can  be  manipulated  directly  at  the  language 
level.  Fabric  also  has  array  objects,  to  support  larger  data  aggregates.  Tike  Java 
objects.  Fabric  objects  are  mutable  and  are  equipped  with  a  notion  of  identity. 

Naming 

Objects  are  named  throughout  Fabric  by  object  identifiers  ( oids ).  An  object  iden¬ 
tifier  has  two  parts:  a  store  identifier,  which  is  a  fully  qualified  DNS  hostname, 
and  a  64-bit  object  number  ( onum ),  which  identifies  the  object  on  that  node. 
An  object  identifier  can  be  transmitted  through  channels  external  to  Fabric,  by 
writing  it  as  a  uniform  resource  locator  (URL)  with  the  form  f  ab :  // store/ onum, 
where  store  is  a  fully  qualified  DNS  hostname  and  onum  is  the  object  number. 
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An  object  identifier  is  permanent  in  the  sense  that  it  continues  to  refer  to  the 
same  object  for  the  lifetime  of  that  object,  and  Fabric  nodes  always  can  use  the 
identifier  to  find  the  object.  If  an  object  moves  to  a  different  store,  acquiring  an 
additional  oid,  the  original  oid  still  works  because  the  original  store  is  respon¬ 
sible  for  keeping  a  forwarding  pointer  in  a  surrogate  object.  Long  forwarding 
chains  of  surrogate  objects  can  reduce  performance  and  reliability;  path  com¬ 
pression  can  be  used  to  avoid  this  [22,28,38]. 

Knowing  the  oid  of  an  object  gives  the  power  to  name  that  object,  but  not 
the  power  to  access  it:  oids  are  not  capabilities  [26].  If  object  names  were  capa¬ 
bilities,  knowing  the  name  of  an  object  would  confer  the  power  to  access  any 
object  reachable  from  it.  To  prevent  covert  channels  that  might  arise  because 
adversaries  can  see  object  identifiers,  object  numbers  are  generated  by  a  crypto¬ 
graphically  strong  pseudo-random  number  generator.  Therefore,  an  adversary 
cannot  probe  for  the  existence  of  a  particular  object,  and  an  oid  conveys  no  in¬ 
formation  other  than  the  name  of  the  node  that  persistently  stores  the  object. 

Fabric  uses  DNS  to  map  hostnames  to  IP  addresses,  but  relies  on  X.509  cer¬ 
tificates  to  verify  the  identity  of  the  named  hosts  and  to  establish  secure  SSL 
connections  to  them.  Therefore,  certificate  authorities  are  the  roots  of  trust  and 
naming,  as  in  the  Web. 

Fabric  applications  can  implement  their  own  naming  schemes  using  Fabric 
objects.  For  example,  a  naming  scheme  based  on  directories  and  path  names  is 
easy  to  implement  using  a  persistent  hash  map. 

Labels 

Every  object  has  an  associated  object  label  that  summarizes  the  confidential¬ 
ity  and  integrity  requirements  associated  with  the  object's  data.  It  is  used  for 
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information-flow  control  and  to  control  access  to  the  object  by  Fabric  nodes. 
The  object  label  is  defined  as  the  trust-ordering  join  of  the  labels  of  the  fields  in 
the  object's  class.  This  join  is  computed  by  the  compiler,  where  possible.  How¬ 
ever,  some  of  this  computation  is  performed  by  the  Fabric  runtime  system.  For 
example,  if  the  compiler  determines  that  an  object  label  depends  on  a  class  pa¬ 
rameter,  which  can  happen  when  a  field  label  uses  a  class  parameter,  then  part 
of  the  object-label  computation  must  be  done  at  run  time,  when  the  object  is 
constructed. 

Classes 

Every  Fabric  object,  including  array  objects,  contains  a  ClassRef,  which  is  a 
reference  to  the  object's  class  that  is  paired  with  the  SHA-256  hash  of  the  class's 
code.  For  classes  stored  in  Fabric,  the  reference  is  the  oid  of  a  class  object,  a  Fabric 
object  that  represents  the  object's  class  in  the  Fabric  language  and  contains  the 
class's  code.  For  other  classes,  the  reference  is  simply  the  Java  fully  qualified 
name  of  the  class. 

The  ClassRef  creates  an  unforgeable  binding  between  each  object  and  the 
correct  code  for  implementing  that  object.  When  objects  are  received  over  the 
network,  the  expected  hash  in  the  object's  ClassRef  is  checked  against  the  actual 
hash  of  the  object's  class. 

Versions 

Fabric  objects  can  be  mutable.  Each  object  has  a  current  version  number,  which 
is  incremented  when  a  transaction  that  updates  the  object  is  committed.  The 
version  number  distinguishes  current  and  old  versions  of  objects.  If  worker 
nodes  try  to  compute  with  out-of-date  object  versions,  the  transaction  will  fail 
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on  commit  and  will  be  retried  with  the  current  versions.  The  version  number  is 
an  information  channel  with  the  same  confidentiality  and  integrity  as  the  fields 
of  the  object;  therefore,  it  is  protected  by  the  same  mechanisms. 

2.3.2  Object  groups 

On  a  store,  objects  are  associated  with  object  groups  containing  a  set  of  related 
objects.  Object  groups  are  the  unit  of  object  distribution:  when  an  object  is 
requested  by  a  worker  or  dissemination  node,  the  entire  group  is  pre-fetched 
from  the  store,  amortizing  the  cost  of  store  operations  over  multiple  objects.  Ev¬ 
ery  object  in  the  object  group  is  required  to  have  the  same  security  policy,  so 
that  the  entire  group  can  be  treated  uniformly  with  respect  to  access  control, 
confidentiality,  and  integrity.  The  binding  between  an  object  and  its  group  is 
not  permanent;  the  store  constructs  object  groups  as  needed  and  discards  infre¬ 
quently  used  object  groups.  To  improve  locality,  the  store  tries  to  create  object 
groups  from  objects  connected  in  the  object  graph. 

2.3.3  Dissemination  and  encryption 

To  avoid  placing  trust  in  the  dissemination  layer,  disseminated  object  groups 
are  encrypted  using  a  symmetric  key  and  signed  with  the  public  key  of  the 
originating  store.  The  symmetric  encryption  key  is  stored  in  a  key  object  that  is 
not  disseminated  and  must  be  fetched  directly  from  its  store.  When  an  object 
group  is  fetched,  the  dissemination  node  sends  the  oid  of  the  key  object  and  the 
random  initialization  vector  needed  for  decryption.  Key  objects  are  ordinarily 
shared  across  many  disseminated  object  groups,  so  workers  should  not  need  to 
fetch  them  often. 
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Phase  I 

Client-authenticated  \ 
SSL  handshake*  ) 


Phase  II 


B’s  server  certificate: 


[B,fcrPUbl 


B  JcA 


A’s  principal  certificate  chain: 
[a’s  Principal  oid,  &pub]^  ,  [sA,  &p“bj 


B’s  principal  certificate  chain. 

|b’s  principal  oid,  fcpUb]SB  >  [^B’  ^ SB  ]CA 


*For  simplicity,  only  certifi¬ 
cate  messages  are  shown  in 
the  SSL  handshake. 


Figure  2.7:  Authentication  protocol  sequence.  Node  A  is  connecting  to  node  B. 


Disseminated  object  groups  are  identified  by  dissemination  nodes  based  on 
the  oid  of  a  contained  object  called  the  head  object.  The  oid  of  the  head  object  is 
exposed  in  the  object  group,  but  other  oids  in  the  object  group  (and  the  contents 
of  all  objects)  are  hidden  by  encryption. 


2.3.4  Node  authentication 

Workers  and  stores  authenticate  each  other  when  communicating  over  the  net¬ 
work.  The  goal  of  authentication  is  to  establish  the  principal  oid  (i.e.,  the  oid  of 
the  principal  object)  of  the  remote  host,  so  that  it  can  be  used  in  authorization 
checks.  Figure  2.7  shows  a  protocol  sequence  diagram  for  the  mutual  authenti¬ 
cation  of  nodes  A  and  B.  Authentication  occurs  in  two  phases. 

In  the  first  phase,  A  connects  to  B  and  performs  a  client-authenticated  SSL 
handshake.  Each  node  B  that  is  capable  of  receiving  connections  has  a  server 
certificate,  which  is  an  X.509  certificate  signed  by  a  certificate  authority  (CA). 
This  certificate  binds  B's  DNS  hostname  to  B's  public  key,  and  is  therefore  simi¬ 
lar  to  an  SSL  certificate  for  the  web.  Whether  the  certificates  of  a  given  CA  are 
accepted  is  decided  by  the  Fabric  node  receiving  them. 

Every  node  A  has  a  principal  certificate  for  performing  SSL  client  authentica- 


40 


tion.  This  is  an  X.509  certificate  that  binds  A's  principal  oid  to  A's  public  key.  The 
certificate  is  signed  by  the  storage  node  that  stores  the  principal  object.  With  the 
store's  server  certificate,  this  gives  a  CA-rooted  certificate  chain  for  the  oid  of 
A's  principal  object. 

After  a  successful  SSL  handshake,  A  knows  it  has  contacted  the  correct  node, 
because  it  knows  the  remote  node  has  B's  private  key.  Similarly,  B  knows  A's 
principal  oid,  because  of  SSL  client  authentication,  so  A  is  authenticated  to  B. 

In  the  second  phase,  B  completes  the  mutual  authentication  by  sending  its 
principal  certificate  to  A.  This  authenticates  B  if  A  can  validate  the  certificate's 
signature,  and  can  match  the  public  key  in  the  certificate  with  the  one  in  B's 
server  certificate. 

Once  the  principal  object  of  a  remote  node  is  established,  it  can  be  used  in 
authorization  checks. 

2.3.5  Authorization  checks 

A  Fabric  node  performs  authorization  checks  to  ensure  confidentiality  and  in¬ 
tegrity  are  maintained  when  sending  or  receiving  data  over  the  network.  Stores 
perform  authorization  checks  in  a  fresh  top-level  transaction  on  a  colocated 
worker.  When  a  worker  w  requests  an  object  with  label  A,  the  store  ensures 
that  the  worker  is  trusted  to  enforce  the  confidentiality  part  of  L  by  checking 
L  E  {t  ->  w}.  Similarly,  when  the  worker  commits  an  update  to  the  object,  the 
store  ensures  that  the  worker  is  trusted  to  enforce  the  integrity  part  of  L  by 
checking  {t  w }  eL 

Workers  perform  analogous  checks  when  receiving  an  object  from  a  store, 
and  when  committing  an  object  to  a  store.  The  authorization  checks  for  remote 
calls  are  the  run-time  checks  described  in  Section  2.2.5. 
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2.3.6  Transaction  management  and  object  locking 

Every  thread  in  the  worker  has  a  transaction  manager  that  holds  transaction 
state.  The  copy  of  each  Fabric  object  at  a  worker  has  a  reader-writer  lock  for 
isolating  transactions  in  different  threads  from  each  other. 

Each  object  also  contains  a  version  number  that  its  store  increments  when  it 
commits  an  update  to  the  object.  These  are  used  to  ensure  consistency  at  commit 
time,  as  described  below. 

During  computation,  the  transaction  manager  logs  the  version  numbers  of 
objects  that  are  read  or  written,  and  the  identities  of  the  objects  that  are  created. 
It  acquires  read  locks  for  objects  that  are  read,  and  write  locks  for  objects  that 
are  written  or  created.  The  first  write  to  an  object  during  a  transaction  also  logs 
the  prior  state  of  the  object  in  an  object  history  so  that  the  transaction  manager 
can  restore  the  object's  state  in  case  the  transaction  aborts. 

Because  transactions  can  be  nested,  transaction  logs  and  object  histories  are 
hierarchical.  When  a  local  sub-transaction  is  created,  it  inherits  the  locks  held  by 
its  parent.  When  the  sub-transaction  commits,  its  log  is  merged  with  the  parent 
transaction  log,  and  its  locks  are  transferred  to  the  parent  transaction.  If  the  sub¬ 
transaction  aborts,  it  discards  its  log,  relinquishes  the  locks  it  has  acquired,  and 
restores  the  state  of  the  objects  it  has  modified. 

To  reduce  logging  overhead,  the  copy  of  each  object  at  a  worker  has  a  reader 
stamp,  which  is  a  reference  to  the  last  transaction  that  read  the  object.  No  logging 
needs  to  be  done  for  a  read  access  if  the  current  transaction  matches  the  reader 
stamp.  Similarly,  each  object  has  a  writer  stamp  for  the  last  transaction  that  mod¬ 
ified  the  object,  and  no  logging  is  needed  if  the  current  transaction  matches  the 
writer  stamp.  Obtaining  the  write  lock  clears  the  reader  stamp. 

When  a  worker  commits  a  top-level  transaction,  it  initiates  a  two-phase  com- 
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mit  protocol  [31]  with  the  stores  for  the  objects  accessed  during  the  transaction. 
The  information  sent  to  each  store  includes  the  version  numbers  of  objects  ac¬ 
cessed  during  the  transaction  and  the  new  data  for  written  objects.  The  store 
checks  that  its  authoritative  version  numbers  match  the  version  numbers  re¬ 
ported  by  the  worker,  to  ensure  the  transaction  used  up-to-date  information. 
For  security,  the  store  also  performs  the  authorization  checks  described  in  Sec¬ 
tion  2.3.5  to  ensure  that  the  worker  is  trusted  to  modify  the  written  objects. 

2.3.7  Memory  management 

To  conserve  memory,  cached  objects  may  be  evicted  if  they  have  no  uncommit¬ 
ted  changes.  In  the  current  implementation,  cached  objects  are  evicted  auto¬ 
matically  by  the  Java  runtime  system,  because  they  are  referenced  using  a  Java 
Sof  tRef  erence  object.  When  an  object  is  modified  or  created,  its  eviction  is  pre¬ 
vented  by  creating  a  hard  reference  to  the  object  in  the  transaction  log.  This  hard 
reference  is  destroyed  when  the  transaction  aborts  or  commits. 

2.3.8  The  security  cache 

The  Fabric  runtime  system  caches  the  results  of  acts-for  tests  and  label  compar¬ 
isons.  This  memoization  mechanism  is  adapted  from  Jif  [14]  and  reduces  the 
overhead  of  these  dynamic  tests. 

The  contents  of  the  cache  is  the  same  as  in  Jif.  Separate  caches  are  kept  for 
positive  and  negative  results  of  acts-for  tests  and  label  comparisons.  As  with 
Jif,  soundness  is  maintained  by  clearing  the  negative  caches  when  a  principal 
delegation  is  added,  and  by  removing  the  positive-cache  entries  that  depend  on 
any  principal  delegation  that  is  removed. 
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In  Fabric,  the  security  cache  is  tied  to  the  transaction  manager,  to  ensure  that 
the  use  of  the  security  cache  does  not  introduce  unsoundness.  Each  transaction 
has  its  own  security  cache,  and  because  transactions  can  be  nested,  the  security 
cache  is  hierarchical.  When  a  sub-transaction  is  created,  it  inherits  the  cache 
entries  from  its  parent.  When  the  sub-transaction  commits,  its  cache  is  merged 
with  the  parent  cache;  if  the  sub-transaction  aborts,  its  cache  is  discarded.  This 
ensures  that  the  security  cache  of  the  parent  transaction  is  isolated  from  changes 
to  the  principal  hierarchy  made  in  an  aborted  sub-transaction. 

2.3.9  Handling  failures  of  optimism 

Computations  on  workers  run  transactions  optimistically,  which  means  that  a 
transaction  can  fail  in  various  ways.  The  worker  has  enough  information  to  roll 
the  transaction  back  safely  in  each  case.  At  commit  time,  the  system  can  detect 
inconsistencies  that  have  arisen  because  another  worker  has  updated  an  object 
that  was  accessed  during  the  transaction.  The  stores  inform  the  workers  which 
objects  involved  in  the  transaction  were  out  of  date;  the  workers  then  flush  their 
caches  of  the  stale  objects  before  retrying  the  transaction. 

Another  possible  failure  is  that  the  objects  read  by  the  transaction  are  already 
inconsistent,  breaking  invariants  on  which  the  application  code  relies.  Broken 
invariants  can  lead  to  errors  in  the  execution  of  the  application.  Incorrectly  com¬ 
puted  results  are  not  an  issue  because  they  will  be  detected  and  rolled  back  at 
commit  time.  Exceptions  may  also  result,  but  as  discussed  earlier,  exceptions 
also  cause  transaction  failure  and  rollback.  Finally,  an  application's  computa¬ 
tion  might  diverge  rather  than  terminate.  Fabric  handles  divergence  by  retrying 
transactions  that  are  running  too  long.  On  retry,  the  transaction  is  given  more 
time  in  case  it  is  genuinely  a  long-running  transaction.  By  geometrically  grow- 
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Figure  2.8:  The  object-subscription  mechanism 

ing  the  retry  timeout,  the  expected  running  time  is  inflated  by  only  a  constant 
factor. 

Because  Fabric  has  subscription  mechanisms  for  refreshing  workers  and  dis¬ 
semination  nodes  with  updated  objects,  the  object  cache  at  a  worker  should 
tend  to  be  up-to-date,  and  inconsistent  computations  in  an  application  can  be 
detected  before  a  transaction  completes. 

2.3.10  Object  subscriptions 

To  help  keep  caches  up  to  date,  workers  and  dissemination  nodes  are  implicitly 
subscribed  to  any  object  group  they  read.  Figure  2.8  illustrates  this  subscription 
mechanism.  When  a  worker  reads  an  object  group  from  a  dissemination  node 
(1),  it  becomes  subscribed  to  the  group  (2).  Workers  and  dissemination  nodes 
that  read  directly  from  a  store  (3)  are  similarly  subscribed  (4). 

When  any  object  in  the  group  is  updated  (5),  the  store  sends  the  updated 
group  to  its  subscribers  (6).  The  dissemination  layer  is  responsible  for  relaying 
group  updates  to  workers  that  have  read  them  (7).  Group  updates  are  delivered 
on  a  best-effort  basis.  On  receipt  of  the  updated  group,  a  worker  can  abort  and 
retry  any  transaction  that  has  read  out-of-date  data. 
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2.4  Support  for  distributed  computation 


Fabric  transactions  can  be  distributed  across  multiple  workers  by  executing  re¬ 
mote  calls  within  a  transaction.  The  whole  transaction  runs  in  isolation  from 
other  Fabric  transactions,  and  its  side  effects  are  committed  atomically.  The 
ability  to  distribute  transactions  is  crucial  for  reconciling  expressiveness  with 
security.  Although  some  workers  are  not  trusted  enough  to  read  or  write  some 
objects,  it  is  secure  for  them  to  perform  these  updates  by  calling  code  on  a  suffi¬ 
ciently  trusted  worker.  This  section  describes  the  features  of  the  runtime  system 
that  support  secure  distributed  transactions. 

2.4.1  Writer  maps 

In  a  distributed  transaction,  an  object  can  be  shared  and  updated  by  multiple 
workers.  This  is  challenging.  For  consistency,  workers  need  to  compute  on  the 
latest  version  of  the  shared  object  as  it  is  updated.  For  performance,  workers 
should  be  able  to  locally  cache  objects  that  are  shared  but  not  updated.  For 
security,  updates  to  an  object  with  confidentiality  L  should  not  be  learned  by  a 
worker  w  unless  Le{t  ->  w}.  To  allow  workers  to  efficiently  check  for  updates  to 
objects  they  are  caching,  without  revealing  information  to  workers  not  trusted 
to  learn  about  updates.  Fabric  introduces  writer  maps. 

Every  object  used  during  a  distributed  transaction  has  a  writer,  which  is  the 
worker  that  last  updated  the  object  during  the  transaction.  The  object's  writer, 
therefore,  stores  the  definitive  copy  of  the  object  for  the  transaction.  Every  trans¬ 
action  has  a  writer  map  that  records  the  writer  for  each  object  used  in  the  trans¬ 
action.  The  writer  map  is  passed  through  the  distributed  computation  along 
with  control  flow. 
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When  a  worker  w  updates  an  object,  the  object's  writer  w'  is  notified  and 
relinquishes  the  role.  The  notifying  worker  w  becomes  the  new  writer,  and  this 
change  is  recorded  in  the  writer  map.  Notification  of  the  old  writer  w'  is  not  a 
covert  channel,  because  the  program-counter  label  pc  of  the  write  must  be  lower 
than  the  object's  label  L,  which  the  old  writer  is  already  trusted  to  read: 

pc  E  L  E  {T  -*■  w'} 

The  writer  map  contains  two  kinds  of  mappings:  writer  mappings  and  label 
mappings.  An  update  to  object  o  at  worker  w  adds  a  writer  mapping  with  the 
form  hash{ oid,  tid,  key)  {w}key,  where  oid  is  the  oid  of  object  o,  tid  is  the 
identifier  for  the  top-level  transaction,  and  key  is  the  encryption  key  for  o,  stored 
in  o's  key  object.  This  mapping  permits  a  worker  that  has  the  ability  to  read  or 
write  o — and  therefore  has  the  encryption  key  for  o — to  learn  whether  there 
is  a  corresponding  entry  in  the  writer  map,  and  to  determine  which  node  is 
currently  the  object's  writer.  Nodes  lacking  the  key  cannot  exploit  the  writer 
mapping  because  without  the  key,  they  cannot  verify  the  hash.  Because  the 
top-level  transaction  id  is  included  in  the  hash,  they  also  cannot  watch  for  the 
appearance  of  the  same  writer  mapping  across  multiple  transactions. 

Label  mappings  support  object  creation.  The  creation  of  a  new  object  with 
oid  oid  adds  an  entry  with  the  form  hash( oid)  h>  oidlabel,  where  oidlabel  is  the 
oid  of  the  object's  label,  which  contains  the  object's  encryption  key.  This  second 
kind  of  mapping  allows  a  worker  to  find  the  encryption  key  for  newly  created 
objects,  and  then  to  check  the  writer  map  for  a  mapping  of  the  first  kind. 

The  writer  map  is  an  append-only  structure,  so  if  an  untrusted  worker  fails 
to  maintain  a  mapping,  it  can  be  restored.  The  size  of  the  writer  map  is  a  side 
channel,  but  the  capacity  of  this  channel  is  bounded  by  always  padding  out  the 
number  of  writer  map  entries  added  by  each  worker  to  the  next  largest  power 
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of  2,  introducing  dummy  entries  containing  random  data  as  needed.  Therefore 
a  computation  that  modifies  n  objects  leaks  at  most  lg  lg  n  bits  of  information. 

The  writer  map  is  threaded  through  the  distributed  computation  along  with 
control  flow:  it  is  included  in  every  remote-call  request,  and  is  returned  with  the 
result  of  the  call.  Each  worker  in  the  computation  keeps  a  local  version  number 
for  the  writer  map,  and  increments  this  version  number  when  incorporating 
new  writer-map  information  from  a  remote-call  request  or  a  remote-call  result. 

During  computation,  while  logging  an  object  access,  the  transaction  man¬ 
ager  checks  the  writer  map.  If  a  writer  is  found,  the  latest  version  of  the  object 
is  fetched  from  the  writer,  and  for  write  accesses,  the  writer  role  is  transferred. 

To  reduce  overhead,  the  copy  of  each  object  at  a  worker  has  a  writer-map 
stamp,  which  records  the  version  number  of  the  writer  map  seen  during  the 
previous  access.  No  fetch  needs  to  be  done  if  the  current  writer-map  version 
number  matches  the  writer-map  stamp. 

2.4.2  Distributed  transaction  management 

To  maintain  consistency,  transaction  management  must  in  general  span  multiple 
workers.  A  worker  maintains  transaction  logs  for  each  top-level  transaction  it 
is  involved  in.  These  transaction  logs  must  be  stored  on  the  workers  where  the 
logged  actions  occurred,  because  the  logs  may  contain  confidential  information 
that  other  workers  may  not  see.  For  example,  in  the  code  below,  the  existence 
of  a  or  b  in  the  transaction  log  can  reveal  the  value  of  secret. 

int  x; 

if  (secret)  x  =  a.f; 

else  x  =  b .  f ; 
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Figure  2.9  illustrates  the  log  structures  that  could  result  during  a  distributed 
transaction  involving  three  workers.  Each  transaction,  including  nested  trans¬ 
actions,  is  identified  by  a  randomly  generated  transaction  id  (tid).  (For  clarity, 
the  figure  uses  sequential  tids.)  Each  remote-call  request  includes  the  tids  for 
the  call's  entire  transactional  context.  This  allows  the  receiving  worker  to  syn¬ 
chronize  its  transaction  state  with  that  of  the  calling  worker. 

In  Figure  2.9a,  a  transaction  (tid=01)  starts  on  worker  A,  then  calls  code 
on  worker  B,  which  starts  a  nested  sub-transaction  (tid=02)  there.  Because 
the  request  from  worker  A  includes  the  context  ctxt=01,  worker  B  knows  that 
tid=02  occurs  within  tid=01.  The  code  then  calls  to  worker  C,  starting  an¬ 
other  sub-transaction  (tid=03),  which  finally  calls  back  to  worker  B,  starting 
sub-transaction  tid=04.  Conceptually,  all  the  transaction  logs  together  form  a 
single  log  that  is  distributed  among  the  participating  workers,  as  shown  at  the 
bottom  of  the  figure. 

When  worker  B  returns  to  worker  C,  it  commits  tid=04,  resulting  in  the 
state  shown  in  Figure  2.9b.  The  procedure  for  committing  a  sub-transaction 
with  a  distributed  transaction  log  is  the  same  as  for  a  transaction  with  a  non- 
distributed  log.  To  commit  tid=04,  worker  B  merges  its  portion  of  the  log  for 
tid=04  with  that  of  tid=03.  Though  worker  C  also  has  a  portion  of  the  log  for 
tid=03,  the  two  parts  are  kept  separate. 

Figure  2.9c  shows  the  state  of  the  distributed  transaction  log  after  worker 
C  returns  to  worker  B,  and  tid=03  has  committed.  Before  returning,  worker  C 
commits  its  portion  of  tid=03,  so  it  merges  its  log  for  tid=03  with  that  of  tid=02. 

When  control  returns  from  a  remote  call,  the  worker  always  commits  up  to 
the  context  in  which  the  remote  call  occurred.  Therefore,  when  worker  B  re¬ 
ceives  control,  it  also  commits  its  portion  of  tid=03  so  it  can  continue  working 
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Figure  2.9:  Distributed  transaction  logs 


within  tid=02.  This  merges  worker  B's  portion  of  tid=03  (which  includes  en¬ 
tries  from  tid=04)  with  tid=02. 

The  return  from  worker  B  to  worker  A  is  elided.  The  diagram  looks  like 
that  in  Figure  2.9c,  except  worker  B  has  merged  tid=02  into  tid=01.  Although 
a  similar  merge  does  not  happen  at  worker  C,  this  is  not  a  problem,  because  the 
merge  will  occur  when  worker  C  receives  control  again,  or  when  the  top-level 
transaction  commits.  Figure  2.9d  shows  the  former  case.  Worker  A  calls  worker 
B  again,  which  starts  tid=05  and  calls  worker  C,  starting  tid=06. 

When  a  worker  receives  a  remote  call,  it  compares  its  transactional  context 
with  the  one  it  receives.  The  worker  synchronizes  its  transaction  log  by  com¬ 
mitting  up  to  the  most  recent  common  ancestor  of  the  two  contexts,  and  starting 
any  transactions  it  has  missed.  Therefore,  when  worker  C  receives  the  remote 
call,  it  compares  its  transactional  context  (01 : 02)  with  the  one  it  receives  (01 : 05). 
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Figure  2.10:  A  hierarchical,  distributed  transaction 

It  commits  up  to  the  most  recent  common  ancestor,  tid=01,  and  starts  the  trans¬ 
action  it  has  missed,  tid=05,  before  starting  tid=06  for  the  incoming  call. 

When  the  top-level  transaction  commits,  workers  A,  B,  and  C  participate  in  a 
hierarchical  commit  protocol  to  communicate  with  the  stores  of  the  objects  they 
have  accessed,  using  their  respective  parts  of  the  logs. 

2.4.3  Hierarchical  commit  protocol 

In  general,  a  transaction  may  span  worker  nodes  that  do  not  trust  each  other. 
This  creates  both  integrity  and  confidentiality  concerns.  An  untrusted  node  can¬ 
not  be  relied  to  commit  its  part  of  a  transaction  correctly.  More  subtly,  the  com¬ 
mit  protocol  might  also  cause  an  untrusted  node  to  learn  information  it  should 
not.  Just  learning  the  identities  of  other  nodes  that  participated  in  a  transaction 
could  allow  sensitive  information  to  be  inferred.  Fabric's  hierarchical  two-phase 
commit  protocol  avoids  these  problems. 

For  example,  consider  a  transaction  that  updates  objects  owned  by  a  bank 
and  other  objects  owned  by  an  airline,  perhaps  as  part  of  a  transaction  in  which 
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a  customer  purchases  an  air  ticket  (see  Figure  2.10).  The  bank  and  the  airline  do 
not  necessarily  trust  each  other;  nor  do  they  trust  the  customer  purchasing  the 
ticket.  Therefore  some  computation  is  run  on  workers  managed  respectively  by 
the  bank  and  the  airline.  When  the  transaction  is  to  be  committed,  some  updates 
to  persistent  objects  are  recorded  on  these  different  workers. 

Because  the  airline  and  the  bank  do  not  trust  the  customer,  their  workers 
will  reject  remote  calls  from  the  customer — the  customer's  worker  lacks  suffi¬ 
cient  integrity.  Therefore,  this  scenario  requires  the  customer  to  find  a  trusted 
third  party.  As  shown  in  the  figure,  a  third-party  broker  can  receive  requests 
from  the  customer,  and  then  invoke  operations  on  the  bank  and  airline.  Because 
the  broker  runs  at  a  higher  integrity  level  than  the  customer  that  calls  it.  Fabric's 
endorsement  mechanism  must  be  used  to  boost  integrity.  This  reflects  a  security 
policy  that  anyone  is  allowed  to  make  requests  of  the  broker.  It  is  the  responsi¬ 
bility  of  the  broker  to  sanitize  and  check  the  customer  request  before  endorsing 
it  and  proceeding  with  the  transaction. 

The  hierarchical  commit  protocol  begins  with  the  worker  that  started  the 
top-level  transaction.  It  initiates  commit  by  contacting  all  the  stores  for  whose 
objects  it  is  the  current  writer  in  the  writer  map,  and  all  the  other  workers  to 
which  it  has  issued  remote  calls.  These  other  workers  then  recursively  do  the 
same,  constructing  a  commit  tree.  This  process  allows  all  the  stores  involved  in 
a  transaction  to  be  informed  about  the  transaction  commit,  without  relying  on 
untrusted  workers  to  choose  which  workers  and  stores  to  contact  and  without 
revealing  to  workers  which  other  workers  and  stores  are  involved  in  the  trans¬ 
action  lower  down  in  the  commit  tree.  The  two-phase  commit  protocol  then 
proceeds  as  usual,  except  that  messages  are  passed  up  and  down  the  commit 
tree  rather  than  directly  between  a  single  coordinator  and  the  stores. 
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Of  course,  a  worker  in  this  tree  could  be  compromised  and  fail  to  correctly 
carry  out  the  protocol,  causing  some  stores  to  be  updated  in  a  way  that  is  incon¬ 
sistent  with  other  stores.  However,  a  worker  that  could  do  this  could  already 
have  introduced  this  inconsistency  by  simply  failing  to  update  some  objects  or 
by  failing  to  issue  some  remote  method  calls.  In  our  example  above,  the  broker 
could  cause  payment  to  be  rendered  without  a  ticket  being  issued,  but  only  by 
violating  the  trust  that  was  placed  in  it  by  the  bank  and  airline.  The  customer's 
power  over  the  transaction  is  merely  to  prevent  it  from  happening  at  all,  which 
is  not  a  security  violation. 

Once  a  transaction  is  prepared,  it  is  important  for  the  availability  of  the  stores 
involved  that  the  transaction  is  committed  quickly.  The  transaction  coordinator 
should  remain  available,  and  if  it  fails  after  the  prepare  phase,  it  must  recover 
in  a  timely  way.  An  unavailable  transaction  coordinator  could  become  an  avail¬ 
ability  problem  for  Fabric,  and  the  availability  of  the  coordinator  is  therefore 
a  trust  assumption.  To  prevent  denial-of-service  attacks,  prepared  transactions 
are  timed  out  and  aborted  if  the  coordinator  is  unresponsive.  In  the  example 
given,  the  broker  can  cause  inconsistent  commits  by  permanently  failing  after 
telling  only  the  airline  to  commit,  in  which  case  the  bank  will  abort  its  part 
of  the  transaction.  This  failure  is  considered  a  violation  of  trust,  but  in  keep¬ 
ing  with  the  security  principles  of  Fabric,  the  failing  coordinator  can  only  affect 
the  consistency  of  objects  whose  integrity  it  is  trusted  to  enforce.  This  design 
weakens  Fabric's  consistency  guarantees  in  a  circumscribed  way,  in  exchange 
for  stronger  availability  guarantees. 
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2.5  Implementation 


The  Fabric  implementation  uses  a  mixture  of  Java,  FabIL,  and  Fabric  code.  Not 
counting  code  ported  to  FabIL  from  earlier  Java  and  Jif  libraries,  the  implemen¬ 
tation  includes  a  total  of  35k  lines  of  code. 

In  addition  to  a  common  base  of  7.7k  lines  of  code  supporting  the  worker, 
store,  and  dissemination  nodes,  the  worker  is  implemented  as  3.8k  lines  of  Java 
code  and  3.1k  lines  of  FabIL  code;  the  store  is  1.9k  lines  of  Java;  and  the  dissem¬ 
ination  layer  is  1.2k  lines  of  Java  code.  In  addition,  some  of  the  GNU  Classpath 
collection  libraries  have  been  ported  to  FabIL  for  use  by  Fabric  programs  (an¬ 
other  6.3k  lines  of  code). 

The  Fabric  compiler,  supporting  both  Fabric  and  FabIL  source  files,  is  a  Ilk- 
line  extension  to  the  Jif  3.3  compiler  [56],  itself  a  30k-line  extension  to  the  Poly¬ 
glot  compiler  framework  [59]. 

Implementing  Fabric  in  Java  has  the  advantage  that  it  supports  integration 
with  and  porting  of  legacy  Java  applications,  and  access  to  functionality  avail¬ 
able  in  Java  libraries.  However,  it  limits  control  over  memory  layout  and  pre¬ 
vents  the  use  of  many  implementation  techniques.  In  an  ideal  implementation, 
the  virtual  machine  and  JIT  would  be  extended  to  support  Fabric  directly.  For 
example,  the  Java  SoftReference  capability  that  is  used  for  eviction  could  be 
implemented  with  fewer  indirections.  We  leave  VM  extensions  to  future  work. 

2.5.1  Store 

The  current  store  implementation  uses  Berkeley  DB  [60]  as  a  backing  store  in 
a  simple  way:  each  object  is  entered  individually  with  its  onum  as  its  key  and 
its  serialized  representation  as  the  corresponding  value.  Because  stores  cache 
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both  object  groups  and  object  versions  in  memory,  and  because  workers  are  able 
to  aggressively  cache  objects,  the  performance  of  this  simple  implementation  is 
reasonable  for  the  applications  we  have  studied.  For  write-intensive  workloads, 
object  clustering  at  the  backing  store  is  likely  to  improve  performance;  we  leave 
this  to  future  work. 

It  is  important  for  performance  to  keep  the  representation  of  an  object  at  a 
store  and  on  the  wire  compact.  Therefore,  references  from  one  object  to  another 
are  stored  as  onums  rather  than  as  full  oids.  A  reference  to  an  object  located  at 
another  Fabric  node  is  stored  as  an  onum  that  is  bound  at  that  store  to  the  full 
oid  of  the  referenced  object.  This  works  well  assuming  most  references  are  to  an 
object  in  the  same  store. 

2.5.2  Dissemination  layer 

The  current  dissemination  layer  is  built  using  FreePastry  [69],  extended  with 
proactive  popularity-based  replication  based  on  Beehive  [64].  The  popularity- 
based  replication  algorithm  replicates  objects  according  to  their  popularity,  with 
the  aim  of  achieving  a  constant  expected  number  of  hops  per  lookup. 

One  standard  configuration  of  Fabric  worker  nodes  includes  a  colocated  dis¬ 
semination  node  to  which  dissemination-layer  requests  are  directed;  with  this 
configuration,  the  size  of  the  dissemination  layer  scales  in  the  number  of  worker 
nodes. 


2.5.3  Memory  management 

The  current  implementation  uses  Java's  SoftRef erence  feature  for  memory 
management.  To  achieve  this,  the  FabIL  compiler  translates  each  class  into  a 
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pair  of  classes,  a  .Proxy  class  and  an  _Impl  class,  that  follow  the  delegation  de¬ 
sign  pattern.  Conceptually,  Fabric  objects  refer  to  each  other  through  .Proxy 
instances.  Each  such  instance  has  a  SoftRef  erence  to  its  corresponding  _Irapl, 
and  contains  code  that  delegates  to  the  _Impl.  The  _Impl  class  contains  the  actual 
class  code,  and  its  instances  are  the  actual  objects. 

If  an  object  has  not  been  modified,  its  _Impl  object  will  only  be  accessible 
through  the  SoftRef  erences  in  its  .Proxy  objects.  This  gives  the  JVM  discretion 
to  collect  the  _Impl  when  there  is  memory  pressure.  When  an  object  is  created  or 
modified,  a  direct  reference  to  its  _Impl  is  added  to  transaction  log,  preventing 
the  .Irapl  from  being  garbage-collected. 

Figure  2.11  shows  a  FabIL  class  C  and  its  Java  translation.  The  class  C  has  two 
fields  x  and  y,  and  a  method  m  that  copies  y  to  x  and  assigns  a  new  C  instance  to  y. 
The  class  is  translated  into  an  interface  C  with  a  pair  of  nested  classes,  .Proxy  and 
_Impl,  which  implement  the  interface.  The  interface  exposes  a  getter-setter  pair 
for  each  field  (lines  2-3),  and  a  method  corresponding  to  each  method  declared 
in  the  source  class  (line  4). 

The  .Proxy  class  (lines  6-8)  extends  the  superclass's  .Proxy  class.  All  .Proxy 
classes  ultimately  inherit  from  fabric .  lang.  Object .  .Proxy,  which  holds  the 
SoftRef  erence  to  the  corresponding  .Irnpl  object.  Each  .Proxy  method  dele¬ 
gates  to  the  .Irnpl  object.  Line  7  shows  the  translation  for  the  method  m.  It  first 
obtains  the  .Irnpl  object  by  calling  f  et  ch  ( ) .  This  will  fetch  the  .Irnpl  object  if  the 
JVM  has  evicted  it  from  memory,  or  if  the  object  has  been  updated  by  another 
node  in  the  transaction.  Once  it  has  the  .Irapl  object,  the  code  then  delegates  to 
it  by  calling  the  appropriate  method. 

The  .Irapl  class  (lines  10-20)  extends  the  superclass's  .Irnpl  class,  and  has 
the  actual  field  data  (line  11)  and  the  actual  implementations  of  C's  methods. 


56 


class  C  extends  D  implements  I  { 

C  x,y; 

void  m(Store  s)  {  x  =  y;  y  =  new  C@s();  } 

} 

(a)  FabIL  class 

1  interface  C  extends  D,  I  { 

2  C  get$x();  C  set$x(C  val) ; 

3  C  get$y();  C  set$y(C  val); 

4  void  m(Store  s) ; 

5 

6  static  class  _Proxy  extends  D._Proxy  implements  C  { 

7  void  m(Store  s)  {  ((C._Impl)  f etch() ) ,m(s) ;  }  ... 

3  } 

9 

10  static  class  _Impl  extends  D._Impl  implements  C  { 

n  C  x,y; 

u  C  get$x()  { 

13  TransactionManager . getlnstance () . registerRead(this) ; 

14  return  this.x; 

15  } 

16  void  m(Store  s)  { 

17  set$x(get$y () ) ; 

is  set$y((C)  new  C . _Impl (s) . SgetProxy () ) ; 

19  }  .  .  . 

20  }  .  .  . 

21  } 

(b)  Java  translation 

Figure  2.11:  A  FabIL  class  and  its  Java  translation 


Field-accessor  methods  call  into  the  transaction  manager  to  register  read/write 
operations  (line  13).  Field  accesses  are  translated  into  calls  to  the  appropriate 
accessor  methods  (line  17).  New  object  instances  are  created  by  constructing  an 
_Impl  object,  and  immediately  calling  a  SgetProxy  method  to  obtain  its  _Proxy 
(line  18). 
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2.5.4  Unimplemented  features 

Most  of  the  Fabric  design  described  in  this  dissertation  has  been  implemented  in 
the  current  prototype.  A  few  features  are  not,  though  no  difficulties  are  foreseen 
in  implementing  them:  distributed  deadlock  detection  via  edge  chasing  [11], 
timeout-based  abort  of  possibly  divergent  computations,  timeout-based  abort 
of  prepared  transactions  for  availability,  subscriptions,  retry  and  abort  state¬ 
ments,  path  compression  for  pointer  chains  created  by  mobile  objects,  and 
avoidance  of  read  channels  at  dissemination  nodes. 

2.6  Evaluation 

2.6.1  Course  Management  System 

To  examine  whether  Fabric  can  be  used  to  build  real-world  programs,  and  how 
its  performance  compares  to  common  alternatives,  we  ported  a  portion  of  a 
course  management  system  (CMS)  [7]  to  FabIL.  CMS  is  a  54k  line  J2EE  web 
application  written  using  EJB  2.0  [23],  backed  by  an  Oracle  database.  It  has 
been  used  for  course  management  at  Cornell  University  since  2005;  at  present, 
it  is  used  by  more  than  40  courses  and  more  than  2,000  students. 

Implementation  CMS  uses  the  model /view /controller  design  pattern;  the 
model  is  implemented  with  Enterprise  JavaBeans  using  Bean-Managed  Per¬ 
sistence.  For  performance,  hand-written  SQL  queries  are  used  to  implement 
lookup  and  update  methods,  while  generated  code  manages  object  caches  and 
database  connections.  The  model  contains  35  Bean  classes  encapsulating  stu¬ 
dents,  assignments,  courses,  and  other  abstractions.  The  view  is  implemented 
using  Java  Server  Pages. 
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We  ported  CMS  to  FabIL  in  two  phases.  First,  we  replaced  the  Enterprise  Jav- 
aBean  infrastructure  with  a  simple,  non-persistent  Java  implementation  based 
on  the  Collections  API.  We  ported  the  entire  data  schema  and  partially  imple¬ 
mented  the  query  functionality  of  the  model,  focusing  on  the  key  application 
features.  Of  the  35  Bean  classes,  five  have  been  fully  ported.  By  replacing  com¬ 
plex  SQL  queries  with  object-oriented  code,  we  were  able  to  simplify  the  model 
code  a  great  deal:  the  five  fully  ported  classes  were  reduced  from  3,100  lines 
of  code  to  740  lines,  while  keeping  the  view  and  controller  mostly  unchanged. 
This  intermediate  version,  which  we  will  call  the  Java  implementation,  took  one 
developer  a  month  to  complete  and  contains  23k  lines  of  code. 

Porting  the  Java  implementation  to  FabIL  required  only  superficial  changes, 
such  as  replacing  references  to  the  Java  Collections  Framework  with  references 
to  the  corresponding  Fabric  classes,  and  adding  label  and  store  annotations.  The 
FabIL  version  adds  fewer  than  50  lines  of  code  to  the  Java  implementation,  and 
differs  in  fewer  than  400  lines.  The  port  was  done  in  less  than  two  weeks  by 
an  undergraduate  initially  unfamiliar  with  Fabric.  These  results  suggest  that 
porting  web  applications  to  Fabric  is  not  difficult  and  results  in  shorter,  simpler 
code. 

A  complete  port  of  CMS  to  Fabric  would  have  the  benefit  of  federated,  secure 
sharing  of  CMS  data  across  different  administrative  domains,  such  as  different 
universities,  assuming  that  information  is  assigned  labels  in  a  fine-grained  way. 
It  would  also  permit  secure  access  to  CMS  data  from  applications  other  than 
CMS.  We  leave  this  to  future  work. 

Performance  The  performance  of  Fabric  was  evaluated  by  comparing  five  dif¬ 
ferent  implementations  of  CMS:  the  production  CMS  system  based  on  EJB  2.0, 
the  in-memory  Java  implementation  (a  best  case),  the  FabIL  implementation,  the 
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Page  Latency  (ms) 

Course 

Students 

Update 

EJB 

305 

485 

473 

Hilda 

432 

309 

431 

FabIT 

35 

91 

191 

FabIT/  memory 

35 

57 

87 

Java 

19 

21 

21 

Table  2.1:  CMS  page  load  times  (ms)  under  continuous  load 


FabIL  implementation  running  with  an  in-memory  store  ("FablL/memory"), 
and  a  fifth  implementation  developed  earlier  using  the  Hilda  language  [77]. 
Comparing  against  the  Hilda  implementation  is  useful  because  it  is  the  best¬ 
performing  prior  version  of  CMS.  The  performance  of  each  of  these  systems 
was  measured  for  some  representative  user  actions  on  a  course  containing  55 
students:  viewing  the  course  overview  page,  viewing  information  about  all  stu¬ 
dents  enrolled  in  the  course,  and  updating  the  final  grades  for  all  students  in 
the  course.  All  three  of  these  actions  are  compute-  and  data-intensive. 

All  Fabric  and  Java  results  were  acquired  with  the  app  server  on  a  2.6  GHz 
single-core  Intel  Pentium  4  machine  with  2  GB  RAM.  The  Hilda  and  EJB  results 
were  acquired  on  slightly  better  hardware:  the  Hilda  machine  had  the  same 
CPU  and  4  GB  of  memory;  EJB  results  were  acquired  on  the  production  config¬ 
uration,  a  3  GHz  dual-core  Intel  Xeon  with  8  GB  RAM. 

Table  2.1  shows  the  median  time  to  perform  three  user  actions  under  con¬ 
tinuous  load,  for  each  of  the  measured  systems.  The  first  three  measurements 
in  Table  2.1  show  that  the  Fabric  implementation  of  CMS  runs  faster  than  the 
previous  implementations  of  CMS.  The  comparison  between  the  Java  and  non- 
persistent  FabIT  implementations  illustrates  that  much  of  the  run-time  over¬ 
head  of  Fabric  comes  from  transaction  management  and  from  communication 
with  the  remote  store. 
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2.6.2  Travel  example 

Fabric  can  be  used  to  build  secure  distributed  applications,  in  which  transac¬ 
tions  span  mutually  distrusting  workers.  To  evaluate  this  use,  we  built  a  simple 
prototype  of  the  bank-airline  example  described  in  Section  2.4.3. 

This  application  models  an  interaction  between  mutually  distrusting  users, 
banks,  and  merchants.  Each  principal  has  security  concerns:  banks  are  con¬ 
cerned  that  users  and  merchants  only  modify  account  balances  in  allowed  ways, 
and  users  and  merchants  are  concerned  that  their  accounts  are  modified  only 
when  they  decide  to  participate  in  a  transaction. 

These  concerns  are  reflected  in  the  labels  placed  on  the  objects  implementing 
banks,  accounts,  users,  and  merchants.  These  labels  restrict  the  possible  place¬ 
ment  of  the  data  in  the  system.  For  example,  a  bank  account  is  conceptually 
represented  as  follows:9 

class  Account [principal  bank]  { 
final  Principalfbank^bank}  user; 
int{bank->user ;  bank^bank}  balance;  .  .  . 

> 

To  satisfy  the  integrity  policy,  accounts  must  be  stored  at  a  bank  machine. 

Some  operations  in  the  example  require  trusted  code.  For  example,  the 
createAccount  operation  should  be  executable  by  any  user,  yet  it  must  modify 
the  list  of  accounts,  which  the  bank  considers  to  be  high  integrity.  Implementing 
such  operations  requires  information  downgrading;  static  and  runtime  checks 
force  such  code  to  be  explicitly  approved  by  the  affected  principals,  and  to  exe¬ 
cute  on  workers  trusted  by  those  principals. 

9In  actuality,  the  account  balance  is  broken  out  into  a  separate  object,  to  prevent  the  confi¬ 
dentiality  of  the  balance  from  tainting  the  account's  object  label. 
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total 

app 

tx 

log 

fetch 

store 

Cold 

9,153 

10% 

2% 

12% 

74% 

2% 

Warm 

6,043 

27% 

3% 

6% 

61% 

3% 

Hot 

840 

46% 

14% 

24% 

0% 

17% 

Table  2.2:  Breakdown  of  007  traversal  time  (times  in  ms) 

The  application  core  is  about  400  lines  of  Fabric  code.  Surrounding  this  core 
is  another  1,000  lines  of  Fabric  code  to  provide  a  web  interface  built  on  a  Fabric 
port  of  SIF  [14].  The  labels  and  the  trust  relationships  ensure  its  code  and  data 
are  mapped  securely  onto  the  available  nodes.  Because  of  the  mutual  distrust  in 
this  example,  transactions  are  committed  using  the  hierarchical  commit  protocol 
described  in  Section  2.4.3. 

2.6.3  Run-time  overhead 

To  evaluate  the  overhead  of  Fabric  computation  at  the  worker  when  compared 
to  ordinary  computation  on  non-persistent  objects,  and  to  understand  the  effec¬ 
tiveness  of  object  caching  at  both  the  store  and  the  worker,  we  used  the  007 
object-oriented  database  benchmark  [9].  We  measured  the  performance  of  a 
read-only  (Tl)  traversal  on  an  007  small  database,  which  contains  153k  objects 
totalling  24  MB.  Performance  was  measured  in  three  configurations:  (1)  cold; 
(2)  warm,  with  stores  caching  object  groups;  and  (3)  hot,  with  both  the  store  and 
worker  caches  warmed  up. 

Table  2.2  summarizes  these  measurements  and  breaks  down  the  running 
times  into  time  spent  on  application  code  (app),  on  local  transaction  process¬ 
ing  (tx),  on  logging  reads  and  writes  (log),  on  fetching  objects  from  the  store 
(fetch),  and  on  waiting  for  the  store  to  process  transaction  messages  (store). 

The  results  show  that  caching  is  effective  at  both  the  worker  and  the  store. 
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However  the  plain  in-memory  Java  implementation  of  007  runs  in  66  ms, 
which  is  about  10  times  faster  than  the  worker-side  part  of  the  hot  traversal.  Be¬ 
cause  Fabric  is  designed  for  computing  on  persistent  data,  this  is  an  acceptable 
overhead  for  many,  though  not  all,  applications.  For  computations  that  require 
lower  overhead.  Fabric  applications  can  always  incorporate  ordinary  Java  code, 
though  that  code  must  implement  its  own  failure  recovery. 

2.7  Related  work 

Fabric  provides  a  higher-level  abstraction  for  programming  distributed  sys¬ 
tems.  Because  it  aims  to  help  with  many  different  issues,  including  persistence, 
consistency,  security,  and  distributed  computation,  it  overlaps  with  many  sys¬ 
tems  that  address  a  subset  of  these  issues.  However,  none  of  these  prior  systems 
addresses  all  the  issues  tackled  by  Fabric. 

OceanStore  [66]  shares  the  goal  with  Fabric  of  a  federated,  distributed  object 
store.  OceanStore  is  more  focused  on  storage  than  on  computation.  It  provides 
consistency  only  at  the  granularity  of  single  objects,  and  does  not  help  with 
consistent  distributed  computation.  OceanStore  focuses  on  achieving  durabil¬ 
ity  via  replication.  Fabric  stores  could  be  replicated  but  currently  are  not.  Un¬ 
like  OceanStore,  Fabric  provides  a  principled  model  for  declaring  and  enforcing 
strong  security  properties  in  the  presence  of  distrusted  workers  and  stores. 

Prior  distributed  systems  that  use  language-based  security  to  enforce  strong 
confidentiality  and  integrity  in  the  presence  of  distrusted  participating  nodes, 
such  as  Jif  / split  [79],  SIF  [14],  and  Swift  [12],  have  had  more  limited  goals.  They 
do  not  allow  new  nodes  to  join  the  system,  and  they  do  not  support  consistent, 
distributed  computations  over  shared  persistent  data.  They  do  use  program 
analysis  to  control  read  channels  [79],  which  Fabric  does  not. 
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DStar  [80]  controls  information  flow  in  a  distributed  system  using  run-time 
taint  tracking  at  the  OS  level,  with  Flume-style  decentralized  labels  [41].  Like 
Fabric,  DStar  is  a  decentralized  system  that  allows  new  nodes  to  join,  but  does 
not  require  certificate  authorities.  DStar  has  the  advantage  that  it  does  not  re¬ 
quire  language  support,  but  controls  information  flow  more  coarsely  DStar 
does  not  support  consistent  distributed  computations  or  data  shipping. 

Some  previous  distributed  storage  systems  have  used  transactions  to  im¬ 
plement  strong  consistency  guarantees,  including  Mneme  [52],  Thor  [46]  and 
Sinfonia  [1],  Cache  management  in  Fabric  is  inspired  by  that  in  Thor  [10].  Fab¬ 
ric  is  also  related  to  other  systems  that  provide  transparent  access  to  persistent 
objects,  such  as  ObjectStore  [43]  and  GemStone  [8].  These  prior  systems  do  not 
focus  on  security  enforcement  in  the  presence  of  distrusted  nodes,  and  do  not 
support  consistent  computations  spanning  multiple  compute  nodes. 

Distributed  computation  systems  with  support  for  consistency,  such  as  Ar¬ 
gus  [47]  and  Avalon  [35],  usually  do  not  have  a  single-system  view  of  persistent 
data  and  do  not  enforce  information  security.  Emerald  [6]  gives  a  single-system 
view  of  a  universe  of  objects  while  exposing  location  and  mobility,  but  does 
not  support  transactions,  data  shipping  or  secure  federation.  InterWeave  [74] 
synthesizes  data-  and  function-shipping  in  a  manner  similar  to  Fabric,  and  al¬ 
lows  multiple  remote  calls  to  be  bound  within  a  transaction,  remaining  atomic 
and  isolated  with  respect  to  other  transactions.  However,  InterWeave  has  no 
support  for  information  security.  The  work  of  Shrira  et  al.  [73]  on  exo-leases 
supports  nested  optimistic  transactions  in  a  client-server  system  with  discon¬ 
nected,  multi-client  transactions,  but  does  not  consider  information  security. 
MapJAX  [57]  provides  an  abstraction  for  sharing  data  structures  between  the 
client  and  server  in  web  applications,  but  does  not  consider  security.  Other 
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recent  language-based  abstractions  for  distributed  computing  such  as  X10  [71] 
and  Live  Objects  [63]  also  raise  the  abstraction  level  of  distributed  computing 
but  do  not  support  persistence  or  information-flow  security. 

Some  distributed  storage  systems  such  as  PAST  [68],  Shark  [2],  CFS  [20],  and 
Boxwood  [49]  use  distributed  data  structures  to  provide  scalable  file  systems, 
but  offer  weak  consistency  and  security  guarantees  for  distributed  computation. 


65 


CHAPTER  3 


DEFINING  AND  ENFORCING  REFERENTIAL  SECURITY 

Referential  integrity  guarantees  that  named  resources  can  be  accessed  when 
referenced.  This  an  important  property  for  reliability  and  security  In  dis¬ 
tributed  systems,  however,  the  attempt  to  provide  referential  integrity  can  itself 
lead  to  security  vulnerabilities  that  are  not  currently  well  understood. 

In  this  chapter,  we  identify  three  kinds  of  referential  security  vulnerabilities 
related  to  the  referential  integrity  of  distributed,  persistent  information.  Secu¬ 
rity  conditions  corresponding  to  the  absence  of  these  vulnerabilities  are  formal¬ 
ized.  A  language  model  is  used  to  capture  the  key  aspects  of  programming 
distributed  systems  with  named,  persistent  resources  in  the  presence  of  an  ad¬ 
versary.  The  referential  security  of  distributed  systems  is  proved  to  be  enforced 
by  a  new  type  system. 

3.1  Language  model 

3.1.1  Modelling  distributed  computing  as  a  language 

We  model  referentially  secure  distributed  computing  using  a  core  programming 
language  that  we  call  A persist-  One  motivation  for  a  language-based  model  is 
the  popularity  of  high-level  language-based  models  for  distributed  computing. 
Similarly  to  A persistr  widely  used  middleware-based  systems  make  distributed 
and  persistent  information  appear  to  be  ordinary  language  objects:  they  aim 
to  make  persistence  and  distribution  more  transparent.  These  systems  include 
CORBA  [61],  Java  RMI  [62],  and  J2EE/EJB  [23].  Fabric  and  various  other  re¬ 
search  systems  also  take  this  approach  (e.g.,  [5,6]).  Prior  work  has  also  compiled 
high-level  programs  to  distributed  realizations.  This  approach  has  been  devel- 
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oped  for  web  applications  (e.g.,  [12, 19,  72])  and  for  more  general  distributed 
applications  (e.g.,  [27,78]).  We  expect  our  language  model  will  help  with  under¬ 
standing  the  security  of  all  such  language-based  systems. 

In  addition,  A persist  should  give  insight  into  referential  security  in  systems 
that  do  not  attempt  to  make  persistence  and  distribution  transparent,  because 
A persist  faithfully  models  referential  security  in  such  systems  as  well. 

In  A  persist,  persistence,  distribution,  and  communication  are  implicit  but 
are  constrained  by  policy  annotations.  Programs  in  A persist  are  assumed  to  be 
mapped  onto  distributed  host  nodes  in  some  way  that  agrees  with  these  anno¬ 
tations.  This  mapping  could  be  done  manually  by  the  programmer,  or  automat¬ 
ically  by  a  compiler. 

This  implicit  translation  to  a  distributed  implementation  means  that  some 
apparently  ordinary  source-level  operations  may  be  implemented  using  dis¬ 
tributed  communication  and  computation,  much  in  the  same  manner  as  in  Fab¬ 
ric.  For  example,  function  application  may  be  implemented  as  a  remote  pro¬ 
cedure  call.  Similarly,  following  references  at  the  language  level  may  involve 
communication  between  nodes  to  fetch  referenced  objects. 

Although  the  concrete  mapping  from  source-level  constructs  onto  host 
nodes  is  left  implicit,  we  can  nevertheless  faithfully  evaluate  the  security  of 
source-level  computations.  The  key  is  to  ensure  that  the  system  is  secure  un¬ 
der  any  possible  concrete  mapping  that  is  consistent  with  the  policy  annotations 
in  the  source  program.  That  is,  any  given  computation  or  information  might 
be  located  on  any  host  that  satisfies  the  source-level  security  constraints.  The 
technical  contribution  of  this  chapter  is  to  develop  an  effective  system  of  such 
source-level  constraints,  expressed  as  a  type  system. 

Although  we  refer  to  A persist  as  a  source  language,  little  attempt  is  made  to 
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make  this  language  congenial  to  actual  programming.  In  particular,  the  type 
annotations  introduced  would  be  onerous  in  practice.  They  could  be  inferred 
automatically  using  standard  techniques,  but  we  leave  this  to  future  work.  One 
can  view  the  type  system  as  describing  a  program  (or  system)  analysis,  and  the 
formal  results  of  this  chapter  as  a  demonstration  that  this  analysis  achieves  its 
security  goals. 

3.1.2  Objects  and  references 

Persistent  objects  are  modelled  in  A persist  as  records  with  mutable  fields.  The 
fields  of  an  object  can  point  to  other  objects  through  references.  References  con¬ 
tain  the  names  of  these  mutable  objects.  References  are  not  assignable  as  in 
ML  [51];  imperative  updates  are  achieved  by  assigning  to  mutable  fields. 

The  language  has  two  types  of  references:  hard  and  soft.  A  hard  reference  is 
a  reference  with  referential  integrity:  a  promise  that  the  referenced  object  will 
not  be  destroyed  if  its  host  is  trustworthy.  Because  of  this  promise,  hard  ref¬ 
erences  can  only  be  created  by  trusted  code.  A  soft  reference  does  not  create  an 
obligation  to  maintain  the  referenced  object.  When  following  a  soft  reference 
or  an  untrusted  hard  reference,  a  program  must  be  prepared  to  handle  a  failure 
in  case  the  referenced  object  no  longer  exists.  For  example,  a  garbage  collector 
may  destroy  objects  reachable  only  via  soft  references.  Hard  links  in  Unix  and 
references  in  Java  are  examples  of  hard  references.  URLs,  Unix  symbolic  links, 
and  Java  Sof  tRef  erence  objects  are  examples  of  soft  references. 

This  simple  data  model  can  represent  many  different  kinds  of  systems,  such 
as  distributed  objects,  databases,  and  the  Web.  The  shared  directory  structure 
shown  in  Figure  3.1  serves  as  a  running  example.  Alice  and  Bob  are  travelling 
together  and  are  using  the  system  to  share  photos  and  itineraries.  The  root 


68 


"\  A 


P  =  -L 

Figure  3.1:  Directory  example 


directory  is  kept  on  a  host  R.  Alice  and  Bob  keep  their  directory  objects  on  their 
own  hosts,  A  and  B,  respectively  To  share  sightseeing  ideas,  they  use  a  common 
scratchpad  stored  on  host  U.  Solid  arrows  in  the  figure  represent  hard  references, 
and  dashed  arrows  are  soft  references.  The  a  and  p  annotations  are  policies, 
which  we  now  explain. 


3.2  Policies  for  persistent  programming 


3.2.1  Persistence  policies 

Referential  integrity  ensures  that  a  pointer  can  be  followed  to  its  referent — that 
there  are  no  dangling  pointers.  In  a  federated  system,  referential  integrity  can- 
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not  be  absolute,  because  the  referenced  object  may  be  located  on  an  untrusted, 
perhaps  maliciously  controlled,  host  machine.  Therefore,  referential  integrity 
must  be  constrained  by  the  degree  of  trust  in  the  referenced  host.  This  con¬ 
straint  is  expressed  by  assigning  each  object  a  persistence  policy  expressing  how 
much  it  can  be  trusted  to  remain  in  existence. 

The  precise  form  of  the  persistence  policy  is  left  abstract.  Persistence  policies 
p  are  assumed  to  be  drawn  from  a  bounded  lattice  (£,  4)  of  policy  levels  with  least 
element  l  and  greatest  element  T.  If  pi  =?  p2  for  two  persistence  policies  p\  and 
p2,  then  p2  describes  an  object  at  least  as  persistent  as  that  described  by  pi. 

While  this  description  might  seem  to  leave  persistence  policies  too  abstract 
to  be  meaningful,  they  have  a  simple,  concrete  interpretation.  Absent  repli¬ 
cation,  objects  are  located  only  on  host  nodes  that  are  trusted  to  enforce  their 
persistence  policies,  so  a  persistence  policy  p  corresponds  to  a  set  of  sufficiently 
trusted  host  nodes  H  (p).  Therefore,  if  pi  =>  p2,  then  p2  must  be  enforceable  by  a 
smaller  set  of  hosts:  H (pi)  2  H(p2).  In  fact,  it  is  reasonable  to  think  of  a  policy  p 
as  simply  a  set  of  hosts. 

For  example,  in  Figure  3.1,  the  root  directory  has  persistence  policy  T  and  is 
kept  on  host  R,  which  is  trusted  to  enforce  this  policy.  Alice  and  Bob  each  have 
a  user  directory  with  their  own  persistence  policy  (alice  and  bob,  respectively) 
and  is  stored  on  their  own  host  (A  and  B,  respectively).  The  shared  scratchpad  is 
kept  on  an  untrusted  host  U,  which  enforces  the  persistence  policy  1. 

Persistence  policies  are  integrated  into  the  type  system  of  A persist-  The  type 
of  an  object  reference  includes  a  lower  bound  on  the  persistence  policy  of  the 
object  it  refers  to;  the  type  system  ensures  that  the  persistence  of  the  object  is 
always  at  least  as  high  as  that  of  any  reference  pointing  to  it.  Programs  can 
therefore  use  the  persistence  of  a  reference  to  determine  whether  the  reference 
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can  be  trusted  to  be  intact.  This  rule  enables  sound  reasoning  about  persistence 
and  referential  integrity  as  the  graph  of  objects  is  traversed. 

For  example,  in  Figure  3.1,  while  Alice  and  Bob  both  have  a  hard  reference 
to  the  scratchpad,  they  must  be  prepared  for  a  persistence  failure  when  using 
the  reference.  The  type  system  of  A persist  will  ensure  their  code  handles  such  a 
failure.  Any  reference  to  the  scratchpad  must  have  a  type  with  l  persistence, 
because  it  can  be  no  higher  than  the  1  persistence  of  the  scratchpad  itself. 

In  A  persist,  persistence  is  defined  not  by  reachability,  but  by  policy.  This  re¬ 
solves  by  fiat  one  of  the  three  problems  identified  earlier:  accidental  persistence. 
Accidents  are  avoided  by  allowing  programmers  to  express  their  intention  ex¬ 
plicitly.  An  object  that  is  not  intended  to  be  persistent  is  prevented  from  being 
treated  as  a  persistent  object. 

3.2.2  Characterizing  the  adversary 

Security  involves  an  adversary,  and  is  always  predicated  on  assumptions  about 
the  power  of  the  adversary.  In  the  kind  of  decentralized,  federated  system  under 
consideration,  the  adversary  is  assumed  to  control  some  of  the  nodes  in  the 
system. 

Different  participants  in  a  distributed  system  may  have  their  own  view¬ 
points  about  who  the  adversary  is,  yet  all  participants  need  security  assurance. 
Therefore,  a  given  adversary  is  modelled  as  a  point  a  in  the  lattice  of  persistence 
policy  levels.  In  the  host-set  interpretation  of  persistence  policies,  a  defines  the 
set  of  trusted  hosts  that  the  adversary  does  not  control.  If  an  object's  persistence 
is  not  at  least  as  high  in  the  lattice  as  a,  the  adversary  is  assumed  to  have  the 
power  to  delete  (i.e.,  violate  the  persistence  of)  that  object,  because  it  is  poten¬ 
tially  stored  at  a  host  node  controlled  by  the  adversary. 
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The  formal  results  for  the  security  properties  enforced  by  A  persist  treat  the 
adversary  as  an  arbitrary  parameter.  Therefore,  these  properties  hold  for  any 
adversary 

3.2.3  Storage  attacks  and  authority  policies 

We  introduce  the  idea  of  storage  attacks,  in  which  a  malicious  adversary  tries  to 
prevent  reclamation  of  object  storage  by  exploiting  the  enforcement  of  referen¬ 
tial  integrity  For  example,  in  Figure  3.1,  Bob  has  shared  with  Alice  an  album 
containing  the  photos  he  has  so  far  taken  during  their  trip.  Bob  doesn't  consider 
the  album  to  be  private,  so  others  may  create  references  to  his  album,  as  Alice 
has  done.  However,  an  adversary  that  creates  a  hard  reference  to  this  album  can 
prevent  Bob  from  reclaiming  its  storage. 

To  prevent  such  storage  attacks,  we  ensure  that  hard  references  can  be  cre¬ 
ated  only  in  sufficiently  trusted  code.  We  introduce  creation  authority  to  ab¬ 
stractly  define  this  power  to  create  new  references.  This  is  the  only  action  re¬ 
quiring  some  form  of  authority  in  our  discussion,  so  for  brevity,  we  refer  to 
creation  authority  simply  as  authority. 

Like  persistence  policies,  authority  policies  a  are  assumed  to  be  drawn  from 
a  bounded  lattice  (£,  =?)  of  policy  levels.  Without  loss  of  expressive  power,  they 
are  assumed  to  be  drawn  from  the  same  lattice  as  persistence  policies.  Authority 
prevents  storage  attacks  because  hard  references  can  only  be  created  to  objects 
whose  authority  policy  a  is  less  than  or  equal  to  the  authority  of  the  process  ap. 
That  is,  we  require  a  4  ap. 

A  hard  reference  is  a  reference  that  should  have  referential  integrity,  so  creat¬ 
ing  hard  references  requires  authority.  The  adversary  is  assumed  to  have  some 
ability  to  create  hard  references,  described  by  its  authority  level  a.  Soft  refer- 
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ences  do  not  keep  an  object  alive,  so  no  creation  authority  is  required  to  create 
a  soft  reference. 

In  Figure  3.1,  the  root  directory  has  the  authority  policy  1,  so  anyone  can 
create  a  hard  reference  to  it.  Bob's  philly  album  is  large,  so  he  has  given  it  the 
authority  policy  bob;  only  he  can  create  hard  references  that  prevent  the  album 
from  being  deleted.  Therefore,  Alice's  reference  to  the  album  must  be  soft.  Alice 
has  drafted  an  itinerary,  giving  it  the  authority  policy  {alice.  bob}  to  indicate  she 
will  persist  the  document  for  as  long  as  Bob  requires.  Bob's  reference  to  the 
itinerary,  therefore,  can  be  hard. 

It  may  sound  odd  to  posit  control  over  creation  of  references.  But  a  reference 
with  referential  integrity  is  a  contract  between  the  referrer  and  the  referent.  For 
example,  the  node  containing  the  referent  is  obligated  to  notify  the  referrer  if 
the  object  moves.  Entering  into  a  contract  requires  agreement  by  both  parties, 
so  it  is  reasonable  for  the  node  containing  the  referent  to  refuse  the  creation  of  a 
reference. 

3.2.4  Integrity 

Thus  far,  the  enumerated  powers  of  the  adversary  include  creating  references  to 
low-authority  objects  and  destroying  objects  with  low  persistence.  Because  the 
adversary  may  control  some  nodes,  the  adversary  can  also  change  the  state  of 
objects  located  at  these  nodes.  This  may  in  turn  affect  code  running  on  nodes 
not  controlled  by  the  adversary,  if  the  adversary  supplies  inputs  to  that  code,  or 
if  the  adversary  affects  the  decision  to  run  that  code. 

Integrity  levels  describe  limitations  on  these  effects  of  the  adversary.  An 
integrity  level  w  is  drawn  from  a  bounded  lattice  (£.  4)  of  policy  levels;  without 
loss  of  expressive  power,  it  is  assumed  to  be  the  same  lattice  as  for  persistence 
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and  authority  policies.  The  ordering  =?  corresponds  to  increasing  integrity.  If 
w i  ^  iv 2,  an  information  flow  from  level  u'2  to  w \  would  be  secure:  more-trusted 
information  would  be  affecting  less- trusted  information.1 

In  A persist /  each  variable  and  each  field  of  an  object  has  an  associated  integrity 
level  describing  how  trusted  it  is,  and  hence  how  powerful  an  adversary  must 
be  to  damage  it.  The  integrity  of  a  reference  is  the  integrity  of  the  field  or  vari¬ 
able  it  was  read  from.  Each  object  also  has  a  persistence  and  an  authority  level, 
which  we  can  think  of  as  the  integrity  of  other,  implicit  attributes  of  the  object. 
For  persistence,  this  implicit  attribute  is  the  existence  of  the  object  itself.  For  au¬ 
thority,  the  attribute  is  the  set  of  incoming  references  to  the  object.  This  unifying 
view  of  different  policies  as  different  aspects  of  integrity  explains  why  all  three 
kinds  of  policies  can  come  from  the  same  lattice. 

The  interpretation  of  these  policies  for  integrity,  authority,  and  persistence  is 
summarized  in  Figure  3.3. 

3.2.5  Integrity  of  dereferences  and  garbage  collection 

An  adversary  can  directly  affect  the  result  of  a  dereference  in  two  ways.  First, 
if  the  reference  has  low  integrity,  the  adversary  can  alter  it  to  point  to  a  differ¬ 
ent  object.  Second,  if  the  referent  has  low  persistence,  the  adversary  can  delete 
it.  Therefore,  the  integrity  of  any  dereference  can  be  no  higher  than  the  in¬ 
tegrity  and  persistence  annotations  on  the  reference.  So,  in  Figure  3.1,  if  Alice 
follows  the  reference  from  her  docs  directory  to  the  scratchpad,  she  obtains  an 
untrusted  result;  the  untrusted  host  U  influences  the  result  by  choosing  whether 
to  delete  the  scratchpad  object. 

More  subtly,  the  adversary  can  manipulate  hard  references  to  influence  the 
1This  ordering  corresponds  to  the  trust  ordering  described  in  Section  2.2.2. 
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Figure  3.2:  Authority  affects  integrity  of  dereferences.  Alice  is  following  her 
soft  reference  to  the  phi lly  album.  An  adversary  can  affect  the  outcome  of  the 
dereference,  because  the  album  has  low  authority,  (a)  The  untrusted  host  U  has 
a  hard  reference  preventing  philly  from  being  garbage  collected;  Alice's  derefer¬ 
ence  succeeds,  (b)  Host  U  has  removed  its  hard  reference,  allowing  philly  to  be 
garbage  collected;  Alice's  dereference  fails. 


garbage  collector,  and  thereby  indirectly  affect  the  result  of  a  dereference.  For 
example,  in  Figure  3.2a,  Alice  is  following  her  soft  reference  to  Bob's  philly 
album.  Bob  has  marked  philly  as  only  requiring  low  authority,  allowing  the 
untrusted,  adversarial  host  U  to  create  a  hard  reference,  and  thereby  prevent¬ 
ing  philly  from  being  garbage-collected.  Therefore,  Alice's  dereference  must 
succeed. 

However,  in  Figure  3.2b,  the  adversary  U  has  removed  its  reference.  Subse¬ 
quently,  philly  has  been  garbage-collected,  and  Alice's  dereference  fails.  The 
adversary  has  indirectly  affected  the  outcome  of  the  dereference.  To  account  for 
this,  the  integrity  of  Alice's  dereference  must  be  no  higher  than  the  authority 
required  by  philly. 
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Figure  3.3:  Interpretations  of  the  extremal  policy  labels 


Variables 

x,  y  e  Var 

Policy  levels 

w,a,p,£  e  C 

Memory  locations 

m  e  Mem 

PC  labels 

pc  ::=  w 

Labelled  record  types 

S  ::=  { Xi  ■  Ti}s 

Storage  labels 

s  ::=  (a,p) 

Labelled  reference  types 

R  ::=  {xi  :  Ti}r 

Reference  labels 

1 

<3 

+ 

II 

Base  types 

b  ::=  bool  n 

72  -R  soft  R 

Types  r  ::=  bw  1 

Values 

v,  u  ::=  x  true 

:alse  *  mb  soft  mb  X(x :  r)[pc].e  (  1„) 

Terms 

e  ::=  v\  V\  V2 

if  v i  then  e2  else 

{Xi  =  Vi}b  v.x 

v\.x  :=  V2  |  soft  e  |  eiiie2  |  exists  v  as  x  :  ei  else  e2 
let  x  =  e\  in  e2 


Figure  3.4:  Syntax  of  X°persist 

3.2.6  Security  properties 

We  now  informally  summarize  how  A persist  prevents  the  three  referential  vulner¬ 
abilities  discussed  earlier:  accidental  persistence,  referential  integrity,  and  stor¬ 
age  attacks.  The  adversary  is  described  by  a  single  point  in  the  lattice  of  policy 
levels,  describing  the  adversary's  ability  to  destroy,  modify,  and  link  to  objects. 
Accidental  persistence  is  prevented  because  persistence  is  determined  by  poli¬ 
cies  expressing  the  programmer's  intent,  rather  than  by  reachability.  Referential 
integrity  is  maintained  by  a  A persist  program  with  respect  to  a  particular  adver¬ 
sary  if  following  hard  references  whose  persistence  and  integrity  are  above  the 
level  of  the  adversary  never  leads  to  an  object  that  has  been  destroyed  by  the 
adversary  or  garbage-collected.  Storage  attacks  are  prevented  if  the  adversary 
is  unable  to  change  the  set  of  high-authority  objects  that  are  reachable  through 
hard  references. 
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3.3  Types  for  persistent  programming 


To  formalize  the  ideas  introduced  in  the  previous  section,  we  introduce  the 
A persist  language,  an  extension  to  the  simply  typed  lambda  calculus.  Its  type 
system  prevents  the  referential  vulnerabilities  identified  above.  Figure  3.4  gives 
the  formal  syntax  of  A persist-  We  first  focus  on  how  it  integrates  policies  for  per¬ 
sistence,  authority,  and  integrity  into  its  types. 

3.3.1  Labels 

We  assume  a  bounded  lattice  (£,  <-)  of  policy  levels  with  least  element  i  and  great¬ 
est  element  T,  from  which  integrity  (w),  authority  (a),  and  persistence  policies 
(p)  are  drawn. 

Objects  and  reference  values  are  annotated  with  storage  labels  consisting  of  a 
creation  authority  policy  and  a  persistence  policy.  All  non-unit  types  r  consist 
of  a  base  type  b  along  with  an  integrity  policy  annotation  w;  fields  and  variables 
thereby  acquire  integrity  policies,  because  they  are  part  of  their  types.  Objects 
do  not  have  their  own  integrity  labels  because  all  of  their  state  is  in  their  fields, 
which  do. 

The  program-counter  label  pc  [24]  is  an  integrity  level  indicating  the  degree 
to  which  the  program's  control  flow  has  been  tainted  by  untrusted  data.  This 
label  restricts  the  side  effects  of  code. 

3.3.2  Example 

Suppose  we  want  to  create  a  hierarchical,  distributed  directory  structure,  such 
as  in  Figure  3.1.  Each  directory  maps  names  to  either  strings,  representing  or¬ 
dinary  files,  or  to  other  directories,  and  contains  a  reference  to  its  parent  direc- 
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tory  (elided  in  the  figure).  To  faithfully  model  ordinary  file  systems,  directories 
higher  in  the  hierarchy  should  be  more  persistent:  if  they  are  destroyed,  so  is 
everything  below. 

A  fully  general  directory  structure  would  require  augmenting  A persist  with 
recursive  and  dependent  types;  for  simplicity,  these  features  have  been  omitted 
from  A  persist  because  they  do  not  appear  to  add  interesting  issues.  However,  we 
can  capture  the  security  of  a  general  directory  structure  by  using  Xpersist  records 
to  build  a  fixed-depth  directory  structure  with  a  fixed  set  of  entry  names  for 
each  directory. 

3.3.3  Modelling  objects  and  references 

The  security  policies  of  A persist  are  about  objects  and  references  to  them.  There¬ 
fore,  Xpersist  extends  the  lambda  calculus  with  records  that  represent  the  content 
of  objects.  The  record  {xi  =  v*}  comprises  a  set  of  fields  x,  with  corresponding 
values  Records  are  not  values  in  the  language;  instead,  they  are  accessed  via 
references  ms ,  where  m  is  the  identity  of  the  object  and  S  =  [xr :  vi }  ,s  gives  its 
base  type.  The  storage  label  s  is  a  pair  (a,p).  The  authority  label  a  is  an  upper 
bound  on  the  authority  required  to  create  a  new  reference  to  the  referent  object. 

References  to  objects  have  labelled  reference  types  {xi :  r)}r.  A  reference  la¬ 
bel  r  is  a  triple  (a+,  a~,p)  that  gives  upper  and  lower  bounds  on  the  authority 
required  by  the  referent,  and  a  lower  bound  on  the  persistence  of  the  referent. 
The  upper  authority  label  a+  prevents  storage  attacks.  The  lower  authority  label  a 
prevents  the  adversary  from  exploiting  garbage  collection  to  damage  integrity. 
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3.3.4  Modelling  distributed  systems 

The  goal  of  the  A persist  language  is  to  model  a  distributed  system  in  which  code  is 
running  at  different  host  nodes.  A  single  program  written  in  A persist  is  intended 
to  represent  such  a  system.  The  key  to  modelling  distributed,  federated  com¬ 
putation  faithfully  is  that  different  parts  of  the  program  can  be  annotated  with 
different  integrity  labels,  representing  the  trust  that  has  been  placed  in  that  part 
of  the  code.  To  model  a  set  of  computations  (subprograms  el)  executing  at  dif¬ 
ferent  nodes,  the  individual  computations  are  composed  in  parallel  (eiii---nen) 
into  a  single  A persist  program. 

From  the  viewpoint  of  a  given  principal  in  the  system,  code  with  a  low  in¬ 
tegrity  label,  relative  to  that  principal,  can  be  replaced  by  any  code  at  all.  For  the 
purposes  of  evaluating  the  security  of  the  system,  this  code  is  in  effect  erased 
and  replaced  by  the  adversary.  Therefore  the  single-program  representation 
faithfully  models  a  distributed  system  containing  an  adversary. 

3.4  Accidental  persistence  and  storage  attacks 

We  present  Xpersist  in  two  phases.  In  this  section,  we  present  X°persist,  a  simplified 
subset  of  Xpersist  that  prevents  accidental  persistence  and  storage  attacks. 

3.4.1  Syntax  of  AjW  , 

Figure  3.4  gives  the  syntax  of  Xpersist.  The  names  x  and  y  range  over  variable 
names  Var;  m  ranges  over  a  space  of  memory  addresses  Mem;  w,  a,  p,  and  t 
range  over  the  lattice  C  of  policy  levels;  s  ranges  over  the  space  of  storage  labels 
£2;  and  r  ranges  over  the  space  of  reference  labels  C3. 

Types  in  X°  ist  consist  of  base  types  with  an  integrity  label  (bw),  and  also 


79 


the  unit  type  1,  which  needs  no  integrity  label.  Base  types  include  booleans, 
functions,  and  two  kinds  of  references  to  mutable  records:  hard  ( R )  and  soft 
(soft  R).  The  metavariable  R  denotes  a  labelled  reference  type. 

The  type  T\  — >  r2  is  an  ordinary  function  type  with  a  pc  annotation  that  is 
a  lower  bound  on  the  pc  label  of  the  caller.  It  gives  an  upper  bound  on  the 
integrity  of  data  the  function  affects,  on  the  authority  level  of  references  the 
function  creates,  and  on  the  authority  level  of  any  references  in  the  function 
body. 

Values  include  variables  x,  booleans  true  and  false,  the  unit  value  *,  typed 
memory  locations  (references)  rns,  soft  references  soft  ms ,  functions  A ( x  : 
T)[pc].e,  and  p-persistence  failures  Lp.  A  function  X(x  :  r)[pc].  e  has  one  argu¬ 
ment  x  with  type  r.  The  pc  component  has  the  same  meaning  as  that  in  function 
types. 

Terms  include  values  v  and  u,  applications  v\  v2,  if  expressions 
if  V\  then  e2  else  e3,  record  constructors  {xi  =  i^}s,  field  selections  v.x,  field  assign¬ 
ments  vi.x  :=  V'2,  soft  references  soft  e,  parallel  composition  eiiie2,  soft-reference 
tests  exists  v  as  x  ■  e\  else  e2,  and  let  expressions  let  x  =  ex  in  e2. 

3.4.2  Example 

Returning  to  the  directory  example  in  Figure  3.1,  Bob  can  add  to  the  itinerary 

with  the  code  below.  It  starts  at  the  root  of  the  directory  structure,  traverses 

down  to  the  itinerary,  and  invokes  an  add  method  to  add  a  museum. 

let  home  =  root. bob 
in  exists  home  as  bob: 

let  docs  =  bob. docs 

itin  =  docs . itinerary 
in  itin. add  "Rodin  Museum" 
else:  ... 
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The  soft  reference  home  to  Bob's  home  directory  may  have  been  snapped 
by  the  garbage  collector,  so  exists  is  used  to  determine  whether  the  reference 
is  still  valid.  If  so,  the  body  of  the  exists  is  evaluated  with  bob  bound  to  a 
hard  reference  to  the  home  directory  (This  reference  can  be  created  because 
the  pc  label  at  this  point  has  sufficient  creation  authority)  The  second  select 
expression,  bob .  docs,  dereferences  the  hard  reference. 

3.4.3  Operational  semantics  of  X°persist 

The  small-step  operational  semantics  of  X°persist  is  given  in  Figure  3.5.  The  no¬ 
tation  e{v/x}  denotes  capture-avoiding  substitution  of  value  v  for  variable  x  in 
expression  e.  The  value  of  a  memory  location  that  has  failed  or  been  garbage- 
collected  is  1. 

Let  Ad  represent  a  memory  that  is  a  finite  partial  map  from  typed  mem¬ 
ory  locations  ms  to  closed  record  values,  and  let  (e,  M)  be  a  system  configura¬ 
tion.  A  small  evaluation  step  is  a  transition  from  (e,  M)  to  another  configuration 

(e',  Ad'),  written  (e,  M)  -*■  (e',  Ad'). 

To  avoid  using  undefined  memory  locations,  we  restrict  the  form  of  (e,  Ad). 
Let  locs(e)  represent  the  set  of  locations  appearing  explicitly  in  e.  A  memory  Ad 
is  well-formed  only  if  every  address  m  appears  at  most  once  in  dom(M),  and 
for  any  location  ms  in  dom(M),  locs(M (ms))  <=  dom(M).  A  configuration  (e,  Ad) 
is  well-formed  only  if  M  is  well-formed,  locs(e)  £  dom(M),  and  e  has  no  free 
variables.  Evaluation  preserves  well-formed  configurations  (see  Lemma  10  in 
Section  3.7.3). 

Most  of  the  operational  semantics  rules  are  straightforward,  but  a  few  de¬ 
serve  more  explanation. 

The  record  constructor  {xi  =  iii}s  (rule  CREATE)  creates  a  new  memory  lo- 
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Figure  3.5:  Small-step  operational  semantics  for  ordinary  (non-adversarial)  ex¬ 
ecution  of  \°persist 


cation  ms  to  hold  the  record.  The  component  S  specifies  the  base  type  and 
storage  label  of  the  record.  The  storage  label  governs  at  what  nodes  the  ob¬ 
ject  can  be  created.  The  function  newloc(M)  deterministically  generates  a  fresh 
memory  location.  If  address-space(M)  represents  the  set  of  location  names  in 
M  (i.e.,  {m  :  3 S.ms  e  dom(M)}),  then  newloc(M)  address-space(M)  and 

newloc(M')  =  newloc(M)  if  address-space(M')  =  address-space(M). 

Parallel  composition  expressions  ei  n e2  evaluate  to  the  unit  value  (rule 

Parallel-Result). 
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The  field-selection  expression  v.x  (rules  SELECT  and  Dangle-Select)  eval¬ 
uates  v  to  a  memory  location  ms .  If  the  location  has  not  failed,  the  result  of 
the  selection  is  the  value  of  the  field  x  of  the  record  at  that  location.  Otherwise, 
a  p-persistence  failure  occurs,  where  p  is  the  persistence  level  of  ms,  written 
p  =  persist  (ms). 

The  field-assignment  expression  V\.x  :=  v2  evaluates  %\  to  a  memory  location 
ms  (rules  ASSIGN  and  DANGLE-ASSIGN)  If  the  location  has  not  failed,  v2  is  as¬ 
signed  into  the  field  x  of  the  record  at  that  location;  otherwise,  a  p-persistence 
failure  occurs  (where  p  =  persist(m5)).  The  notation  M[ms.xc  /;]  denotes  the 
memory  resulting  from  updating  with  value  v  the  field  xc  of  the  record  at  loca¬ 
tion  ms. 

Persistence  failures  propagate  outward  dynamically  (FAIL-PROP)  until  the 
whole  program  fails.  The  full  A persist  language,  defined  in  Section  3.5,  can  handle 
these  failures. 

In  rule  EVAL-CONTEXT,  E  represents  an  ordinary  evaluation  context, 
whereas  F,  in  rule  FAIL-PROP,  specifies  the  contexts  from  which  persistence 
failures  propagate.  Contexts  are  given  as  a  term  with  a  single  hole  (denoted  by 
[  •  ])  in  redex  position.  The  syntax  of  E  specifies  the  evaluation  order. 

The  soft-reference  expression  soft  e  evaluates  e  to  a  hard  reference  and  turns 
it  into  a  soft  reference.  The  soft-reference  test  (exists  v  as  x  :  e\  else  e2)  promotes 
the  soft  reference  v  (if  valid)  to  a  hard  reference  bound  to  x  and  evaluates  e\.  If 
the  reference  is  invalid,  e2  is  evaluated  instead. 

In  rule  GC,  the  notation  g c(G,  ( e ,  M ))  means  that  G  is  a  set  of  locations  that 
is  collectible.  G  is  considered  collectible  if  it  has  no  GC  roots  (i.e.,  hard  references 
in  e),  and  no  location  outside  G  has  a  hard  reference  into  G. 

Definition  1  (GC  roots).  A  location  ms  is  a  GC  root  in  an  expression  e,  written 
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root(m5,e),  if  it  is  a  hard  reference  in  e.  This  is  formally  defined  by  the  following 
inference  rules: 


[Rl] 

[R2] 

root (ms ,  e)  Vm®0.  e  *  raff 

root  (ms,ms) 

root (m5,  soft  e) 

[R3] 

3 i.  root (m  ,  ry) 

[R4] 

root(mS,  v ) 

root (mS,  {xi  =  Vi}S  ) 

root(m5,  v.x ) 

[R5] 

3 i.  root 

[R6] 

root  (ms  ,e) 

root (m  ,  v\.x  '■=  f2) 

root(ms,  A(x:r)[pc].  e) 

[R7] 

3 i.  root (m  ,  ry) 

[R8] 

3f.  root(ms,  efi 

root (m  ,  v\  V2 ) 

root(m's,  let  x  =  ei  in  e2) 

[R9] 

3 i.  root (ms ,  efi 

[RIO] 

3i.  root(m  ,  efi 

root  fns ,  if  ei  then  e2  else  63) 

root(ms,  exists  ei  as  x  :  e2  else  63) 

[Rll] 

3 i.  root (m  ,  efi 
root(m  ,  eiiie2) 

A  persist,  defined  in  Section  3.5,  adds  R12;  and  [\persistl>  defined  in  Section  3.6,  adds  R13: 


[R12] 


3 i.  root {ms  ,ef) 


[R13] 


root  (ms  ,e) 


Q  L  ^J  c1 

root(m  ,  try  e\  catch  p\  e 2)  root(m  ,  [e]) 

Definition  2  (Collectible  groups).  A  set  of  locations  G  is  a  collectible  group  in  a 

configuration  ( e,M ),  written  g c(G,  ( e,M )),  if  it  does  not  contain  any  roots  of  e,  and 
no  location  outside  G  has  a  hard  reference  into  G. 

gc(G,(e,M))  & 


G  <=  dom(M) 

a  (fims  e  G.  root (ms,e)) 

a  V/Uq0  e  dom(M).  (M(mQ°)  tlA  3ms  e  G.  root  (ms ,  M(mo°)))  =>  m q°  e  G 


3.4.4  Subtyping  in  X°pmM 

The  subtyping  judgement  h-  T\  <  r2  states  that  any  value  of  type  T\  can  be  treated 
as  a  value  of  type  r2.  Subtyping  in  \°persist  is  the  least  reflexive  and  transitive 
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[SI] 


n>  m 


[S2] 

[54] 

[55] 


I-  {xi'.Ti,  .  .  .,Xn:Tn}r  <  {xp.Ti  i  •  •  •  5  %m  •  7"ra}r 

H  bi  <  b2 

H  Rl  <  R2  \-W2  3Wi 

1-  soft  Ri  <  soft  R2  I- (h)Wl  <  (b2)w2 

h  r2  <  ri  I -t[<t'2  \-  pcx  4  pc2 

PC 1  pc 2  ] 

I-  n  — >  rx  <  r2  — >  t2 


h  a,i  4  a2 


a2  4  a±  h  p2  4  p\ 


I-  {Xj  •  7"i}(a+ ^  pi)  <  {Xj  •  'Ti}(a+,a2,p 2) 


Figure  3.6:  Subtyping  rules  for 


\° 

persist 


relation  consistent  with  the  rules  given  in  Figure  3.6.  Rule  SI  gives  standard 
width  subtyping  on  records.  Because  records  are  mutable,  there  is  no  depth 
subtyping. 

Subtyping  on  soft  references  is  covariant  (rule  S2).  While  hard  references 
may  be  soundly  used  as  soft  references,  this  is  omitted  for  simplicity. 

Rule  S3  gives  contravariant  subtyping  on  integrity  labels.  Rule  S4  gives 
standard  subtyping  on  functions;  the  additional  pc  component  is  covariant. 
These  are  the  opposite  of  the  rules  typically  seen  in  work  on  information-flow 
security,  accounting  for  our  use  of  the  trust  ordering. 

Rule  S5  gives  subtyping  for  labelled  reference  types.  Subtyping  is  covariant 
on  the  a+  component  of  the  reference  label  and  contravariant  on  the  other  two 
components.  This  ensures  the  bounds  specified  by  the  reference  label  of  the 
subtype  are  at  least  as  precise  as  those  of  the  supertype. 


3.4.5  Static  semantics  of  X°persist 

Typing  rules  for  \°persist  are  given  in  Figure  3.7.  The  notation  auth+(r),  auth  (r), 
and  persist(r)  give  the  upper  authority  (a+),  lower  authority  (a-),  and  persis¬ 
tence  {p)  component  of  a  reference  label  r,  respectively.  The  notation  auth+(s) 
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[t-bool] 

[T-Var] 

[T-LOC] 


[T-IF] 


[T-Abs] 


[T-Record] 


[T-Select] 


[T-Exists] 


[T-Let] 


b  e  {true,  false} 

T]pc\-b\  boolT 
r(x)  =  r 
T;  pc  I-  x  :  t 

*~wf  S  :  rectype  S  =  {x7 Tn}(alP) 
E ;pc  \-  mS  :  ({ xl :  7^}(a,a,p))T 

T-,pc\~  v  '■  bool.,, 


(Vi) 

i-  auth+(r)  ^  pcnw 


T-,pcnw  ei  '■  t 


T;pc  i-  if  v  then  e\  else  '■  r  n  w 
i  ,  x  ■  t  ;  pc  i -  e  :  r 


[T-UNIT] 

[T-Bottom] 

[T-Soft] 

[T-Parallel] 


r ;  pc  I-  *  :  1 
p*  T 

P;pc  H  Ip  :  r 
T;  pc  E-  e  :  if,,, 


/  A  Pc  X 

-ref  (r  — »  t)t  :  type 


pc  ^  pc 

t  VC 


[T-App] 


T;pc  h  X(x:t')[pc'].  e  :  (V  — >  r)T 

-a>/  S  :  rectype  5  =  {xT^i}(a,P) 


t[  <  Ti  i-  author})  pc  h  integ(rj)  =?  pc 


T;  pc  i-  soft  e  :  (soft  i?)t 

r;pc  i-  e*  :  Ti 
I-  auth+(ri)  =5  pc 
T;pc  i-  ei  II 62  :  1 

t~i  ,  (  '  pC'  \ 

T;pc\- Vi  ■■  (t  — *•  t)w 
T;  pc  v2  ■  t 
pc1  <  pen  w 

T;  pc  vi  v2  :  t  n  w 
r ;  pc  Vi :  Tj (Vi) 

i -  p  <  pc 


T;pc\-  {Xi  =  w,}S  :  ({ Xi  :  T;}(a;0jp))T 


r -,pchv:  ({x,;  :  Ti}r)l 
i-  auth+(r)  pc 
w'  -  w  n  persist(r) 


[T-Assign] 


T-pchv  1  :  ({Xj  :  Tj}r)t 
t-  auth+(r)  =?  pc 
T;  pc  I-  i>2  :  r 
t-  r  n  pc  n  u;  <  tc 
i-  auth+(r)  pc  n  tc 


r;pc  l-  X.XC  :  Tc  n  w'  L  J  T;  pc  I- Vi-Xc  :=  t>2  :  1 

T;  pc  v  :  (soft  {xj  :  Tj}r)w  I-  auth+(r)  ^  pc  n  w 
w'  =  autfT(r)  n  persist(r)  n  w  T,  x:  ({xj :  Ti}r)w;  pc  n  w'  h  e\  :  r 
T\pcnw' e2'- t  i- auth+ (r)  =>  pc  n  «/ 

P;  pc  h  exists  v  as  x  :  e\  else  e2  '■  t  nw' 

^;pc^-el:r,  i-  auth+(r')  <  pc 
w  =  integ(r')  pc' =  pen  w 

T,x'.Tr-,pc' e2  ■  t  i-  auth+(x )  =?  pc'  rryn  o  P;pcHe:r'  i-  r'  <  r 


P;  pc  i-  let  x  =  ei  in  e2  :  r  n  rc 


[T-Subsume] 


T;  pc  i-  e  :  t 


Figure  3.7:  Typing  rules  for  A°ers^ 
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[WT1]  \-wf  bool^  :  type  [WT2] 

[WT4] 


y-wf  Rj  ■  type 


[WT5] 

[WT6] 


I -wf  (soft  R)w  ■  type 
i -  pc  4  w  h  auth+(ri)  u  auth+(r2)  =S  pc 

*~wf  ri  :  type  \-wf  T2  ■  type 


[WT3]  ^wf  1  :  type 


^t2)w-  type 
t-wfR  ■  type  (Vl)  h  auth+(rj)  ^  a+  (Vl) 
a+  4  wnp  i -  a~  <  a+ 

*~wf  {{xi  •  Ti} (a+ ,a~ ,p)  )w  •  type 

-wf({xi :  Ti}(a,a,p)) t  :  type  h-  integ(ri)  <  p  (Vt) 


-Wf  {Xi  ■■  n}(a,p)  ■  rectype 


Figure  3.8:  Well-formedness  of  types 


and  persist(s)  give  the  authority  and  persistence  component  of  a  storage  label, 
respectively  The  notation  auth+(r)  gives  the  authority  level  needed  to  create  a 
hard  reference  to  a  value  of  type  r,  the  integrity  of  r  is  integ(r),  and  r  n  £  denotes 
the  type  obtained  by  tainting  (meeting)  the  integrity  of  r  with  t 

auth+(bool)  =  auth+(l)  =  auth+(soft  R)  -  1 
integ (bw)=w  (bw)ni  =  bwni  auth+(ri  r2)  =  pc 

integ(l)  =  T  Inf  =  1  auth+({T~T^}s)  =  auth+(s) 

The  typing  context  includes  a  type  assignment  T  and  the  program-counter 
label  pc.  T  is  a  finite  partial  map  from  variables  x  to  types  r,  expressed  as  a 
finite  list  of  x  :  r  entries.  We  write  x  :  r  e  T  and  T(x)  =  r  interchangeably.  For 
an  expression  e  that  is  well-typed  in  a  context  T ;  pc,  the  type  checker  produces  a 
type  t.  The  typing  assertion  T;  pc  i-  e  :  t,  therefore,  means  that  the  expression  e 
has  type  r  under  type  assignment  T  with  program-counter  label  pc. 

Most  of  the  typing  rules  are  standard  rules,  extended  to  ensure  that  the  pc  is 
sufficiently  high  to  obtain  any  hard  references  that  may  result  from  evaluating 
subexpressions,  and  that  the  pc  is  suitably  tainted  where  appropriate. 

Rule  T-BOTTOM  says  persistence  failures  can  have  any  well-formed  type. 
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Rule  T-Abs  checks  function  values.  It  ensures  that  the  function's  program- 
counter  label  pc'  accurately  summarizes  the  authority  levels  of  the  references 
contained  in  the  closure,  and  that  the  pc  is  high  enough  to  create  this  closure. 
The  body  is  checked  with  program-counter  label  pc' ,  so  in  rule  T- APP,  the  func¬ 
tion  can  only  be  used  by  code  with  sufficient  integrity. 

Rule  T- RECORD  checks  the  creation  of  records.  It  requires  that  the  annota¬ 
tion  S  be  well-formed.  Also,  the  pc  must  be  high  enough  to  create  any  hard 
references  that  appear  in  the  fields,  and  to  write  to  the  fields  themselves. 

When  using  a  hard  reference  V\,  the  pc  must  have  sufficient  authority  to 
possess  V\  (rules  T-SELECT  and  T- ASSIGN).  When  assigning  through  v\,  hard 
references  contained  in  the  assigned  value  v2  also  require  authority.  Since  the 
integrity  and  persistence  of  V\  can  affect  whether  the  assignment  succeeds,  we 
taint  the  pc  with  these  labels  before  comparing  with  the  authority  requirement 
of  v2. 

Rule  T-ExiSTS  checks  soft-reference  validity  tests.  It  ensures  that  the  pc  has 
the  authority  to  promote  the  reference. 

The  rules  for  determining  the  well-formedness  of  types  are  given  in  Fig¬ 
ure  3.8.  In  rule  WT5,  a  reference  type  ({ Xi :  Ti}(a+,a-,p))w  is  well-formed  only  if 
the  upper  authority  label  a+  is  an  upper  bound  on  the  authority  levels  of  the 
field  types  rt.  This  ensures  that  the  upper  authority  label  is  an  accurate  sum¬ 
mary  of  the  authority  required  by  the  fields.  We  also  require  a+  be  bounded 
from  above  by  the  integrity  w  of  the  reference,  since  low-integrity  data  should 
not  influence  the  creation  of  high-authority  references.  To  ensure  that  hosts  are 
able  to  create  hard  references  to  the  objects  they  store,  we  also  require  auth+(r) 
to  be  bounded  from  above  by  the  persistence  level  p  of  the  record. 
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Soft-  ' 
Select 

r  Try-' 
[val 

I"  Try-' 
Esc 


(ms .xc, M)  A  ( v,M ) 

((soft  mS  ).xc,M )  A  (v,M) 
'ip' .  v  *  lpi 

(try  v  catch  p:  e,  M)  ( v ,  M) 

pIp' 

(try  lpf  catch  p:  e,  M )  A  (_Lp/,  AT ) 


Soft- 

Assign 

Try- 

Catch 


(mS .Xc  :=  v,  AT )  A  (i/,  AT^ 
((soft  mS).xc  :=  t>,  AT)  A  (i/,  M1) 
P*P' 

(try  Ip/  catch  p:  e,  AT)  A  (e,  AT) 


E  .  |  try  [  ■  ]  catch  p:  e 


T-Soft- 

Select 


T-Soft- 

ASSIGN 


[T-Try] 


r ;  pc,  'H.y-  v-  (soft  {xi  :  Ti  }r)iu,  T  I-  auth+(rc)  =S  pc 
p  =  auth~(r)  n  persist(r)  n  w  I -  H^  p 

T\pc\H  i-  v.xc  :  rc  n p, p 

T ;  pc;  Hi-  v\‘.  (soft  {xi  :  Ti}r)w,  T  p  =  autfT(r)  n  persist(r)  n  w 
T;  pc;H  i- V2 ’■  t,7  f  r  n  pc  n  p  <  rc  i- auth+ (r)  ^  pc  n  p  i -H^p 

T;  pc;  H  I-  Vi. xc  :=  V2  :  l.p 

T;  pc;  "H,  p  i- ei  :  r,  Ai  tc  =  □  (PUP') 

P'^l 

T;  pc  n  w  n  integ(r);'H  i-  e2  :  r,  X%  •“  auth+(r)  =?  pc 
T;  pc;  'H  1-  try  ei  catch  p:  e2  :  r  n  to,  ( X\ / p )  n 


Figure  3.9:  Additional  small-step  evaluation  and  typing  rules  for  A versist 

3.5  Ensuring  referential  integrity 

In  a  distributed  system,  references  can  span  trust  domains,  so  to  be  secure  and 
reliable,  program  code  must  in  general  be  ready  to  encounter  a  dangling  refer¬ 
ence,  one  perhaps  created  by  the  adversary  Therefore,  we  extend  \°persist  with 
persistence-failure  handlers  to  obtain  the  full  A persist  language  (see  Appendix  3.A.1 
for  its  full  syntax).  The  type  system  of  A  persist,  forces  the  programmer  to  be  aware 
of  and  to  handle  all  potential  failures. 

Because  low-persistence  references  may  be  used  frequently,  handling  persis¬ 
tent  failures  immediately  at  each  use  would  be  awkward.  Instead,  A persist  factors 
out  failure-handling  code  from  ordinary  code  by  treating  failures  as  a  kind  of 
exception. 

The  value  of  (try  ei  catch  p:  ef)  is  the  value  of  evaluating  ei.  If  a  dangling 
pointer  at  persistence  level  p  or  higher  is  encountered,  the  error-handling  ex¬ 
pression  e2  is  evaluated  instead.  A  try  expression  creates  a  context  (ei)  in  which 
the  programmer  can  write  simpler  code  under  the  assumption  that  certain  per- 
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sistence  failures  are  impossible,  yet  without  sacrificing  the  property  that  all  fail¬ 
ures  are  handled. 

3.5.1  Persistence  handler  levels 

To  track  the  failures  that  can  be  handled  in  the  current  context,  a  set  of  persis¬ 
tence  levels  T~L  is  used.  Formally,  'H  is  drawn  from  the  bounded  meet-semilattice 
given  by  the  upper  powerdomain  of  persistence  levels.  The  elements  of  the 
powerdomain  are  the  finitely  generated  subsets2  of  C,  modulo  equivalence  re¬ 
lation  (3.1).  The  ordering  on  these  elements  is  given  by  (3.2).  If  we  choose 
maximal  sets  to  represent  the  equivalence  classes,  then  the  meet  operation  is  set 
union. 

def. 

A~  B  »  V£  e  C.  ((3a  €  A.  a  «  £)  o  (36  e  B.  b  *  £))  (3.1) 

def. 

B  <=>•  V6  e  B.  3a  e  A.  a  ^  6  (3.2) 

pc, 1-1 

Functions  \(x  :  r)[pc]  Ti].  e  and  function  types  T\  — ^  r2  are  extended  with 
an  H  component,  which  is  an  upper  bound  on  the  'H  label  of  the  caller.  It  gives 
a  set  of  lower  bounds  on  the  persistence  levels  of  references  that  the  function 
follows. 


3.5.2  Example 

Returning  to  the  directory  example  in  Figure  3.1,  Alice  can  add  a  place  to  the 
list  of  sightseeing  ideas  with  the  code  below.  This  code  starts  at  Alice's  docs 
directory,  traverses  the  reference  to  the  scratchpad,  and  invokes  an  add  method 
to  add  a  museum. 

2Non-empty  subsets  that  are  either  finite  or  contain  1. 


90 


let  pad  =  docs . scratchpad 
in  try  pad. add  "Rodin  Museum" 
catch  1:  ... 

The  expression  pad .  add  follows  a  hard  reference  to  the  scratchpad.  Despite  the 
hard  reference,  a  try  is  needed  because  Alice  does  not  trust  host  U  to  persist  the 
scratchpad. 

3.5.3  Operational  semantics  of  \persist 

The  small-step  operational  semantics  of  A  persist  extends  that  of  Xpersist  with  the 
rules  in  Figure  3.9.  Two  rules  are  for  using  soft  references  directly,  and  three 
are  for  persistence-failure  handlers.  Failures  propagate  outward  dynamically 
(TRY-ESC)  until  either  they  are  handled  by  a  failure  handler  (Try-Catch),  or 
the  whole  program  fails. 

The  persistence-failure  handler  try  e\  catch  p:  e2  handles  p-persistence  fail¬ 
ures.  (Failures  that  occur  at  persistence  levels  higher  than  p  are  also  considered 
to  be  p-persistence  failures.)  If  e\  fails  with  such  a  failure,  then  e2  is  evaluated; 
otherwise  the  result  of  the  try  is  that  of  e\.  Persistence-failure  handlers  enable  e\ 
to  call  functions  that  require  more  trust  (lower  H)  than  provided  by  the  context. 
Appendix  3.A.2  gives  the  full  operational  semantics  for  A persist- 

3.5.4  Subtyping  in  \persist 

The  subtyping  rules  are  the  same  as  for  \°persist,  except  that  function  subtyping 
is  also  contravariant  on  the  H  component.  Full  subtyping  rules  are  given  in 
Appendix  3.A.3. 
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[Create] 


[Select] 


Soft- 
Select 

Soft- 
Assign 

Exists- 
True 

Exists- 
False 

Bracket- 
Select 

Bracket- 

Soft-Select 

Bracket- 
Soft 

Bracket- 
EXISTS 

Bracket- 
Try 

Bracket- 
Let 

Bracket- 
Context 


M(m°)  =  {xi  =  Vi} 

S  —  { Xi  ■  T*}(a,p) 

(ms .Xc,M)  i  (vc  P,  AT) 

M(ms)  =  l 


1  =  newloc(M)  S  =  {xi  :  T;}s  v[  =  Vi  ►  Q  A 
({xi  =  v'i}S ,M)  i  | mS,M[mS  w-  {xi  =  t>'}] j 

M(ms)  *  1  yp'.v*lj/ 

S  =  :  A  }  (a,/>) 

AT'  =  AT[mS.aic  >-*  t>  >0;  Tc] 

(ms .xc  ■=  v ,  M)  —>(*  *a  p,  AT') 


[Assign] 


M(ms)  =  i 


’Dangle-’ 

S  =  {Xi  :Ti}(0iP) 

’Dangle-’ 

S  -  {xi  : 

Select 

(ms.xc,M)  i  (lp  *-ap,M) 

_  Assign  _ 

{mS .xc  :=  v,  M)  (lp  ►q,  p,  M) 

(ms .xc,M)  (v,M)  S  =  {xi  :  Tj}(aj. 


p) 


((soft  ms  ).xc,  M)  A-  (t>  ►a  (anp),M) 

(mS .xc  :=  v ,  M)  A-  (*/,  M')  5  =  {i7^}(a,P) 

((soft  mS).xc  ■=  v ,  M)  (t/  ►qi  (anp), 

M(mS)  ±  1  S  =  {xi  :  Ti}(a>p) 

(exists  soft  m5  as  a: :  ei  else  e2,  M)  A-  ((eilra5/#})  ►a  (ft  np),  M) 


M(ms)  *  1  S  =  {a*  :  Ti}(a>. 


p) 


(exists  soft  m*5  ass:  ei  else  e2,  M)  (e2  ►c*  (ftfip),  M) 


([ms].a:C)M)  ([ms.:Ec],  M) 

([soft  ms].xc ,  AT ) 
i  ([(soft  ms).xc  ],M) 

(soft  [m5],  AT)  i  ([soft  m  S],M) 

(exists  [11]  as  i :  ej  else  ,  AT) 
i  ([exists  tiasi:  ei  else  e2],  AT) 

(try  [?;]  catch  p:  e,  AT) 
i  ( [try  v  catch  p:  e] ,  AT) 


Bracket- 
Assign 

Bracket- 

Soft-Assign 

Double- 
Bracket 

Bracket- 
Apply 

Bracket- 

If 

Vp.  v  *  lp 


( [mS].a:c  :=  v,  AT)  i  j[ms.ic  :=  u] ,  AT) 

([soft  ms].xc  :=  f ,  AT) 
i  ([(soft  ms).xc  :=  v],  AT) 

<[[«]].  AT)  4  ([w],  AT) 

([A(a;:r)[pc;'H].  e]  v,M) 

—>  {[(A(x:t)[pc;'H].  e)  ti],AT) 

(if  [t>]  then  ei  else  e2,  AT) 
i  {[if  v  then  ei  else  e2],  AT) 


(let  a;  =  [u]  in  e,  AT)  ( [e{ [tt] /aa}] ,  AT) 


(e,  AT)  i  (e',  AT') 
<[e],AT>i([e'],AT') 


Bracket- 

Fail 


(F[[±p]],AT)i([±p],AT) 


Figure  3.10:  Small-step  operational  semantics  extensions  for  ordinary  execution 

of  [  ^persist  ] 
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3.5.5  Static  semantics  of  A persist 

The  typing  rules  for  A persist  extend  those  for  \°persist-  They  augment  the  typing 
context  with  a  handler  environment  H,  indicating  the  set  of  persistence  failures 
the  evaluation  context  can  handle.  For  an  expression  e  that  is  well-typed  in  a 
context  T;  pc;  %,  typing  judgements  additionally  produce  an  effect  X ,  which  is 
a  set  indicating  the  persistence  failures  e  can  produce  during  evaluation.  The 
typing  assertion  T;pc;'H  f-  e  :  r, X,  therefore,  means  that  the  expression  e  has 
type  r  and  effect  X  under  type  assignment  T,  current  program-counter  label  pc, 
and  handler  environment  H . 

The  typing  rules  for  X°persist  are  converted  straightforwardly  to  thread  'H  and 
X  through  typing  judgements.  Rules  T-SELECT  and  T- ASSIGN  gain  premises 
to  ensure  the  context  has  a  suitable  handler  in  case  dereferences  fail.  Ap¬ 
pendix  3.  A.4  gives  the  full  set  of  converted  rules. 

Figure  3.9  gives  three  new  typing  rules.  T-SOFT-SELECT  and  T-SOFT- ASSIGN 
check  direct  uses  of  soft  references.  They  taint  the  integrity  of  the  dereference 
with  autfr(r)  because  the  result  of  the  dereference  is  affected  by  those  able  to 
create  a  hard  reference  and  thereby  prevent  the  referent  from  being  garbage- 
collected  (Section  3.2.5).  Rule  T-TRY  checks  try  expressions.  To  reflect  the  in¬ 
stallation  of  a  p-persistence  handler,  p  is  added  to  the  handler  environment  'H 
when  checking  e\.  The  value  w  in  the  typing  rule  is  a  conservative  summary  of 
the  persistence  errors  that  can  occur  while  evaluating  e\  and  not  handled  by  the 
p-persistence  handler.  Because  evaluation  of  e2  depends  on  the  result  of  e\,  the 
pc  label  for  evaluating  e2  is  tainted  by  w.  In  this  rule,  the  notation  X Ip  denotes 
the  subset  of  persistence  errors  A  not  handled  by  p. 

U/p  =  {p'  e  T-L :  p  p'} 
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[o-Create] 


[u-ASSIGN] 

[u-FORGET] 


m  =  newloc(M)  0;  T ;  T  I—  {xt  =  [v*]}9  :  Rj,  T 

i M[ms  »  {Xi  =  [uj]}]  a  $  persist  (S') 

(e,M)  |e,M[ms  {x*  =  [?;*]}]  j 

m9  e  dom(M)  M(mS)±  1  5  =  {xj :  rjs 

0;  T;  T  h  [t>]  :  tc,  T  1-“^  Af[mS.xc  ^  [x]] 

(e,M)  (e,M[ms.a;c  [x]]) 
m9  e  dom(M)  a  £  persist(S) 
{e,M)~,a(e,M[ms»±]) 


Figure  3.11:  Effects  caused  by  the  cr-adversary 


3.6  The  power  of  the  adversary 


The  power  of  the  adversary  is  modelled  by  extending  the  operational  semantics 
of  Figure  3.5  with  additional  transitions.  To  support  reasoning  about  what  an 
adversary  may  have  affected  in  a  partially  evaluated  program,  A persist  is  aug¬ 
mented  to  include  bracketed  forms.  We  call  the  resulting  augmented  language 
[A persist]-  We  write  [e]  to  indicate  an  expression  that  may  have  been  influenced 
by  the  adversary,  and  [v]  to  indicate  an  influenced  value.  Doubly  bracketed 
values  are  considered  expressions  and  not  values. 

The  extended  syntax  and  the  rule  for  typing  bracketed  forms  appear  below. 
Extensions  for  the  operational  semantics  appear  in  Figure  3.10. 

Values  v  "=  ...  |  [c] 

Terms  e  "=  . . .  |  [e] 


T;  pc  n  £;  T-L  h-  e  :  r,  X 

oijtl  h-  auth+(V)  ^  pc  n  t 
[T-Bracket]  - 


T ;  pc]  h  [e]  :  r  n  £,  X 

The  operational  semantics  is  extended  by  adding  new  rules  that  propagate 
brackets  in  the  obvious  manner.  Rules  CREATE,  SELECT,  DANGLE-SELECT, 
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Assign,  Dangle-Assign,  Soft-Select,  Soft-Assign,  Exists-True,  and 
ExiSTS-FALSE  are  amended  to  ensure  low-integrity  expressions  are  bracketed. 
To  do  this,  they  use  the  auto-bracketing  function  e  ►<*  L  The  notation  e  >a  r  is 
shorthand  for  e  >a  integ(r). 


e 


( 


e, 

[e], 


if  h  a  =>  t  or  3e'.  e 

otherwise. 


[e']; 


Also,  rules  TRY-VAL  and  LET  are  amended  to  prevent  a  transition  when 
v  is  bracketed,  and  rules  that  disallow  transitions  on  bottom  values  (lp)  are 
amended  to  prevent  transitions  on  bracketed  bottom  values. 

It  is  important  to  know  that  any  evaluation  of  a  program  in  the  original  lan¬ 
guage  can  be  simulated  in  the  augmented  language,  which  amounts  to  showing 
that  the  rules  cover  all  the  ways  that  brackets  can  appear.  A  straightforward  in¬ 
duction  proves  this  (see  Lemma  1  in  Section  3.7). 

Rules  for  the  adversary's  transitions  are  given  in  Figure  3.11.  Adversaries 
may  create  new  records,  modify  existing  records,  or  remove  records  from  mem¬ 
ory  altogether,  but  their  ability  is  bounded  by  an  integrity  label  a  e  C.  Such 
an  a-adversary  has  all  creation  authority  except  a  and  higher,  can  modify  any 
record  field  except  those  with  a  (or  higher)  integrity,  and  can  delete  any  record 
except  those  with  a  (or  higher)  persistence.  A  small  evaluation  step  taken  in  the 
presence  of  an  a-adversary  is  a  transition  from  a  machine  configuration  (e,  M) 
to  another  configuration  (e',  M’),  written  (e,  M)  -*-a  (e',  M'). 

While  it  is  reasonable  to  allow  the  adversary  to  create  ill-typed  values,  an  im¬ 
plementation  with  run-time  type  checking  can  catch  ill-typed  values  when  they 
cross  between  hosts  and  replace  them  with  well-typed  default  values.  There¬ 
fore,  the  adversary's  transitions  embody  a  simplifying  assumption  that  the  ad¬ 
versary  can  only  create  well-typed  values. 
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Rule  u-CREATE  lets  the  adversary  create  records  at  new  memory  locations. 

_ v 

The  premise  0;  T;  T  h  {xi  -  [A,]}5  ■  RT,  T  ensures  that  the  records  are  well-typed 
values  and  that  new  hard  references  satisfy  the  restrictions  on  the  adversary 

_ v 

The  premise  M[ms  { x,  =  [/',] }  ]  ensures  that  the  resulting  memory  is 
well-formed  (formally  defined  in  Section  3.7.1),  so  the  adversary  cannot  create 
references  to  unknown  memory  locations. 

Rule  o- ASSIGN  lets  the  adversary  modify  existing  records.  The  premise 
M(ms )  t  l  ensures  that  the  record  being  modified  still  exists  in  memory.  The 
premise  0;  T;  T  h  [v]  :  rc,  T  ensures  that  the  assignment  is  well-typed  and  that 
new  hard  references  satisfy  the  restrictions  on  the  adversary.  The  premise 
M[ms.xc  [/■]  ]  ensures  that  the  resulting  memory  is  well-formed,  so  the 
adversary  cannot  create  references  to  unknown  memory  locations. 

Rule  a -FORGET  lets  the  adversary  drop  records  from  memory.  The  premise 
a  $  persist(S')  restricts  the  persistence  level  of  dropped  records. 


3.7  Results 

The  goal  of  A  persist,  is  to  prevent  accidental  persistence  and  to  ensure  that  the  ad¬ 
versary  cannot  damage  referential  integrity  or  cause  storage  attacks.  Accidental 
persistence  is  prevented  by  the  use  of  persistence  policies.  We  now  show  how 
to  formalize  the  other  security  properties  and  prove  that  A persist  satisfies  these 
properties. 

3.7.1  Well-formedness 

To  ensure  we  consider  only  sensible  memories  and  configurations,  we  define 
well-formedness  for  memories,  and  use  that  in  the  definition  for  configurations. 
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Definition  3  (Well-formed  \persist  memory).  A  Apersist  memory  M  is  well-formed, 
written  h -wf  M,  if  each  record  stored  in  M  satisfies  two  conditions:  the  record's  type 
corresponds  to  the  type  of  the  record's  location  in  M,  and  every  location  mentioned  in 
the  record  is  valid  in  M. 

More  precisely,  whenever  M  maps  a  reference  ms  to  a  record  value  {xt  =  vfi, 

•  S  is  well-formed, 

•  each  Vi  has  the  appropriate  type  (as  specified  by  S), 

•  the  locations  mentioned  in  the  field  values  Vi  are  in  the  domain  of  M: 


dcj".  v  v 

wf  M  ( M(ms )  =  {Xi  =  vfi  a  S  -  { Xi  :  Ti}M 

=>  \~ufS:  rectype 

A  (Vi.  0;  T;  T  l-  'Uj  :  Tj,  t) 

a  locs({a;i  =  i>i})  £  dom(M)) 


Our  notion  of  a  well-formed  configuration  relies  on  knowing  when  a  loca¬ 
tion  is  non-collectible  (cannot  be  garbage  collected),  which  we  now  define. 


Definition  4  (Non-collectible  locations).  A  memory  location  ms  is  non-collectible 
in  a  configuration  (e,  M),  written  n  c(ms,  (e,  M)),  if  it  is  reachable  from  a  GC  root  of  e 
through  a  path  of  hard  references. 

This  is  defined  formally  by  the  following  induction  rules: 


[NCI] 


root(m5,e) 
n c(ms,  ( e,M )) 


[NC2] 


root(mf1,  e)  M  (rnf 1 )  =  {xt  =  vfi 

3c.  r\c(ms,  ( vc ,  M )) 

nc (ms,  (e,M)) 


Well-formedness  of  configurations  is  parameterized  on  an  adversary  a. 


Definition  5  (Well-formed  A  persist  configuration).  A  A  persist  configuration  (e,M)  is 
well-formed,  written  (e,  M),  if  the  following  all  hold: 
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•  M  is  well-formed; 

•  the  locations  mentioned  in  e  are  valid  in  M; 

•  no  non-collectible  high-persistence  location  is  deleted;  and 

•  if  G  is  a  minimal  collectible  group  in  which  a  high-persistence  location  is  deleted, 
then  all  locations  in  G  are  also  deleted. 

Formally, 

def. 

i -%f{e,M)  <=>  \-wf  M  a  locs(e)  £  dom(M) 

A(Vms.nc(ms,  (e,M)) a  h  a  3  persist(S') 

=>  M (ms)  1 1) 

a (VG.  gc(G,  (e,  M))  a  (tG'  c  G.  gc(G',  (e,  M))) 

a (3m  f  €  G.  i-  «  =?  persist(S'o)  a  M(m q°)  =  l) 

=>•  Vms  €  G.  M(ms )  =  l) 

A  Xpersist  configuration  is  well-formed  in  a  non-adversarial  setting,  written  \-wf  (e,  M), 
zf  zf  zs  well-formed  with  respect  to  the  1  adversary. 

Corresponding  well-formedness  conditions  are  defined  similarly  for  [A persist] 
memories,  written  i-j*^  M  and  M,  and  for  [ Xpersist ]  configurations,  written 
(e,M)  and  (e,M).  Well-formedness  of  [A persist]  memories  is  param¬ 
eterized  on  an  a-adversary,  because  values  appearing  in  low-integrity  record 
fields  must  be  bracketed. 

Definition  6  (Well-formed  [A persist]  memory).  A  [  Ar;,;r,„.s/]  memory  M  is  well-formed 
with  respect  to  an  adversary  a  (written  M)  if  it  is  a  well-formed  Xpersist  memory 
and  all  low-integrity  field  values  are  bracketed: 

M  i- wfM  a  (. M(mb )  =  { Xi  =  Vi}  a  S  =  {xi:  Ti}s  a  a  $  integ(r?:) 

=>  3t/.  Vi  =  [V]) 
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Definition  7  (Well-formed  [ Xperfilst ]  configuration).  A  [A persist]  configuration 
(e,  M)  is  well-formed  if  it  is  a  well-formed  \persiSt  configuration  with  a  well-formed 
[A persist]  memory.  A  configuration  is  well-formed  in  a  non-adversarial  setting  if  it  is 
well-formed  in  the  presence  of  a  i  adversary. 

.  ,  def. 

(e’M)  '-[wfi  M/X  HS/(e’M) 

def. 

h[wf]  { c,M )  <=>  \-^  (e,M) 


3.7.2  Completeness  of  [A persist]  evaluation 

For  [A persist]  to  be  adequate  for  reasoning  about  referential  security  properties  of 
A persist /  we  must  be  able  to  simulate  any  A persist  execution  in  [A/)er,„iS/  ].  This  is  a 
completeness  property  To  do  this,  we  first  need  to  define  what  it  means  for  a 
[A  persist]  configuration  to  simulate  a  A  persist  configuration.  This  involves  defining 
a  correspondence  on  expressions  and  heaps  between  the  two  languages. 

We  write  e\  <  e2  to  denote  that  the  A persist  term  e\  corresponds  to  the  [X persist] 
term  e2.  The  terms  correspond  if  erasing  brackets  from  e2  produces  e\. 


Definition  8  (Correspondence  between  [A persist]  arid  A persist  expressions).  A 
[A persist]  expression  e  is  related  to  a  \persist  expression  er,  written  e  <  e' ,  if  the  two 
are  equal  when  brackets  in  e  are  removed.  This  is  formally  defined  by  the  following 
induction  rides. 


e  =  e 


i-  e  <  e' 


i-  e  <  e' 


i-  e  <  e 


h  [e]  <  e' 


A (x:t)[pc\H\.  e  <  A (x:r)[pc;  'H].e' 


H  Vi  <  Ui 


(Vi) 


e*  <  e‘. 


/  (Vi) 


Vi  <  Ui 


(Vi) 


i-  ui  v2  <  u\  ii‘i  v-  if  e±  then  e2  else  e 3  <  if  e[  then  e2  else  e'3  1-  {xi  =  Vi}s  <  {xt  =  Ui}s 

(rides  continued  on  next  page) 
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I -  V  <u 


I -  Vi  <Ui 


.  (Vi) 


I-  e  <  e 


i -  e;  <  e. 


/  (Vi) 


i -v.x<u.x  i-  v\ .x  :=  v2  <  u\  .x  :=  u2  h  soft  e  <  soft  e  h  eiiie2  <  e^ne^ 


,  P.  <  J  (Vi) 


h  exists  ei  as  x  :  e2  else  e 3  <  exists  ass:  else  63 

He<e'(Vi)  he.<e'(Vi) 


I-  try  ei  catch  p :  e 2  <  try  catch  p:  e(>  f-  let  x  =  e\  in  e2  <  let  x  =  e\  in  e2 
This  correspondence  on  expressions  naturally  induces  a  correspondence  on 
heaps,  and  the  two  together  give  the  correspondence  on  configurations. 


Definition  9  (Correspondence  between  [A persist]  and  \persist  memories).  A 
[A persist]  memory  M1  is  related  to  a  Xpersist  memory  M2r  written  Mi  <  M2,  if  they 
map  the  same  set  of  locations,  and  the  memories  map  each  location  to  values  that  are 
related. 

def. 

h-  Mi  <  M2  <=>•  dom(M1)  =  dom(M2) 

a  Vms  e  dom(M1).  Mi(ms)  -  M2(ms )  =  1 

v  h-  Mi(ms )  <  M2(ms ) 


Definition  10  (Correspondence  between  [A persist]  and  A persist  configurations).  A 
[A persist]  configuration  (ex,  Mf  is  related  to  a  A persist  configuration  ( e2,M2 ),  written 
t-  (ei  ,Mi)  <  ( e2 ,  M2),  if  both  the  expressions  and  the  memories  are  related: 

def. 

v-  ( e  1 ,  M 1 )  <  (e2,  M2)  -<=>•  h  ei  <  e2A  h  M\  <  M2 


We  can  now  state  and  prove  the  completeness  of  [Apers^]. 

Lemma  1  (Completeness  of  [A  persist\  with  respect  to  A  persist)-  Let  (e^Mf)  be  a  well- 
formed  Xpersist  configuration  with  ei  well-typed.  Let  (e2lM2)  be  a  well-formed  [Apersjsi] 
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configuration  corresponding  to  (e1,  Mi),  with  e2  well-typed.  If  (ei ,  Mi)  takes  a  ->  tran¬ 
sition  to  (e' ,  M(),  then  there  exists  a  configuration  (e'2,M2)  corresponding  to  (e\ ,  M() 
such  that  (e2,M2)  ->*  ( e2,M2 ). 

C/  (eU  Ml)  A  0;  Pc>  K  H  el  :  T  X 
a  (e2,  M2)  a  0;  pc;  H\-e2'-T,X 
a  h-  (ei,  Mx)  <  (e2,  M2)  a  (ei,  Mi)  -*■  (e\ ,  M[) 

=>  3e' ,  M'2.  (e2,  M2)  (e' ,  M')  a  (e',  M(>  <  (e' ,  M'} 

Proof.  Induction  on  the  derivation  of  (ei,  Mi)  -*-a  (e\ ,  M[).  □ 

3.7.3  Soundness  of  [A persist\  type  system 

We  prove  the  type  system  sound  via  the  usual  method  of  proving  type  preserva¬ 
tion  (Lemma  9)  and  progress  (Lemma  13).  Because  we  are  only  concerned  with 
well-formed  configurations,  it  is  important  to  know  that  they  are  preserved  by 
the  operational  semantics.  This  is  captured  by  Lemma  10. 

We  first  show  some  preliminary  results  for  weakening  the  typing  context. 

Lemma  2  (Type-environment  weakening).  Extra  type  assumptions  can  be  safely 
added  to  typing  contexts:  T;  pc;  PL  i-  e  :  r,  X  a  x  f  FV(e)  =>  T,  x‘-r';pc',  PL  i-  e  :  r,  X. 

Proof.  By  induction  on  the  derivation  of  T;  pc;  t-  e  :  r,  T”.  □ 

Lemma  3  (pc  weakening).  The  pc  label  in  a  typing  context  can  be  safely  raised. 

pc  4  pc'  aP]  pc] PL  e  :  t,  X  =>  P]  pc' ;  Pi  I-  e  :  r,  X 

Proof.  By  induction  on  the  derivation  of  P]pc;PL\-e'-r,X. 
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Rules  T-BOOL,  T-Unit,  T-Loc,  T-Bottom,  and  T-Var  are  trivial  base  cases. 
Rule  T-Abs  follows  from  the  transitivity  of  Rules  T-SOFT,  T-PARALLEL,  and 
T-SUBSUME  follow  from  the  induction  hypothesis. 

Rules  T-Record,  T-Select,  T-Soft-Select,  T- Assign,  T-Soft- Assign, 
T-Exists,  T-APP,  T-Let,  T-Try,  T-If,  and  T-BRACKET  follow  from  the  in¬ 
duction  hypothesis  and  the  transitivity  of  =>.  In  rules  T- ASSIGN  and  T-SOFT- 
ASSIGN,  we  need  to  show  h  rnpc'np  <  tc.  By  assumption,  we  have  h  rnpcnp  <  tc. 
Let  bw  -  t.  Then  using  S3,  we  can  show 

\-b<b  \-wnpcr\p^wn  pc'  n  p 
hrn  pc'  np<m  pc  np  , 

and  the  result  follows  from  transitivity  of  subtyping.  □ 

Lemma  4  (Handler  weakening).  Extra  handler  assumptions  can  be  safely  added  to 
the  typing  context. 

h  H '  ^  EL  a  T;  pc]  H  h  e  :  r,  X  =>  T;  pc]  V. '  h  e  :  r,  X 

Proof.  By  induction  on  the  derivation  of  T;  pc\  PL  e  :  r,  X . 

Rules  T-Bool,  T-Unit,  T-Loc,  T-BOTTOM,  T-Var,  T-Abs,  and  T-PARALLEL 
are  trivial  base  cases. 

Rules  T-Soft,  T-Record,  T-Select,  T- Assign,  T-Soft-Select,  T-Soft- 
Assign,  T-Exists,  T-App,  T-Let,  T-If,  T-Subsume,  and  T-Bracket  follow 
from  the  induction  hypothesis. 

Rule  T-TRY  follows  from  the  induction  hypothesis  and  the  fact  that  'H'u  {p}  4 
H  u  {p}.  □ 

Corollary  5  summarizes  these  results. 
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Corollary  5  (Context  weakening).  Suppose  T]pc]TL  h  e  :  t,X  with  x  FV(e), 
pc  4  pc'  and  TL'  4TL.  Then 


r ,x'-T,',pc';/H'  i -  e:r,X 

We  can  now  prove  the  substitution  lemma. 

Lemma  6  (Substitution).  T,  x ■  r';  pc;  TL  e  :  r,  X  a  0;  pc\TL\-  v-r\  T  =>  T;  pc;  TL  h 
e{v/x}  :  r,  A”. 

Proof.  By  induction  on  the  derivation  of  T,  a; : r';  pc;  TL  i-  e  :  r,  A.  Note  that  since 
v  was  typed  in  an  empty  type  assignment  (r  =  0),  we  must  have  FV(c)  =  0. 
Rules  T-Bool,  T-Unit,  T-Loc,  and  T-BOTTOM  are  trivial  base  cases. 

Rules  T-Soft,  T-Record,  T-Select,  T- Assign,  T-Soft-Select,  T-Soft- 
Assign,  T-App,  T- Parallel,  T-Try,  T-If,  T-Subsume,  and  T-Bracket  follow 
from  the  definition  of  substitution  and  the  induction  hypothesis. 

Case  T-Var: 

Suppose  e  =  x.  Then  e{v/x}  =  v  and  t'  =  r  and  the  result  holds  in  this  case 
via  Corollary  5  and  T-SUBSUME.  Alternatively,  suppose  e  -  y  +  x.  In  this 
case,  e{v/x}  =  e  and  the  result  holds  trivially. 

Case  T-Abs  (e  =  X(y-r1)\pc1]TLi\.  ei): 

If  y  =  x,  then  e{v/x}  =  e  and  the  result  holds  trivially.  Alternatively,  sup¬ 
pose  y  t  x.  We  have  FV(v)  =  0,  so  e{v/x}  -  X(y-Ti)[pc1;'Hi].ei{v/x}.  Let 
T7  =  T,x:t'.  From  the  typing  of  e,  we  have 

F,x:r',y:T1;pc1-,'Hi  ei  :  t2,TLi 

pcuHi  . 

(T1 - 7  A )t  :  type  H  pcx  4  pc 

T,x'-t']  pc,  TL  i—  A(p:ri)[pc1;7fi].ei  :  (n  pCl'H\  r2)T,  T, 
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where  r  =  (ri  P  1  r2)T  and  X  =  T.  So,  we  know  T,:e:t',p:ti;  pep  "Hi  t-  ei  : 
r2,  'H  i .  Therefore,  by  the  induction  hypothesis,  we  have  T,  y  :  t\ :  pc , :  'H  \  \- 
e\{v/x}  :  T2i'H\.  So  the  result  holds  in  this  case  via  an  application  of  T-ABS: 

r,y:rl-,pc1-,'Hi  e^v/x}  :  t2,'Hi 

pc1,Hi 

(Ti - *  t2) t  :  type  H  pc1  «  pc 

pc  ^  ^  2 

T ; pc; h  A(p:ri)[pc1;7ti].ei{c/a:}  :  (ri  >  t2)t,.T. 

Case  T-EXISTS  (exists  u  as  y  :  ex  else  e2): 

From  the  typing  of  e,  we  have 

T ,x:t';  pc]T-L  u  :  (soft  {ap  :  Ti}r)w,  T 
i-  auth+(r)  ^  pc  n  tc  w/  =  auttT(r)  n  persist(r)  n  w 
T ,x:r',y:({xi  :  Ti}r)w;pc,-,'H  H  a  :  r",X1 
T,x:t';  pc' ;  %  i-  e2  :  r",  X2  i-  auth+(r")  ^  pc' 

r,x:T'-,pc-,H  exists  wasp:  e\  else  e2  :  r"  n  w X\  n  X2 , 

where  pc'  -  pcnw',  r  =  t"c\w' ,  and  X  -  XxnX2.  By  the  induction  hypothesis, 
we  therefore  have 

T;  pc;  7i  m{c/x}  :  (soft  {x* :  Ti}r)w,  T  (3.3) 

Tjpc'j'H  h  e2{^/cc}  :  r",  A2  (3.4) 

Suppose  y  =  x.  Then  e{v/x}  =  exists  u{v/x}  asp  :  ei  else  e2{v/x},  so  from 
(3.3)  and  (3.4),  the  result  holds  in  this  case  via  an  application  of  T-EXISTS: 

T;  pc;  "H  t-  u{v/x}  :  (soft  {op  :  r)}r)^,  T 
h  auth+(r)  =>  pc  n  w  w'  =  auth_(r)  n  persist(r)  n  w 
T ,y-({x^Tri}r)w;pc']'H  h  ei  :  t", Ah 
T;  pc';  i-  e2{v/x}  :  t" ,  X2  auth+(r")  ^  pc' 

T;  pc;  i-  exists  u{v/x}  as  y  :  ei  else  e2{v/x}  :  t"  n  w',  Ai  n  A2 . 
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Alternatively,  suppose  y  +  x.  We  have  FV(v)  =  0,  so  e{v/x}  = 
exists  u{v/x}  as  y  :  ei{v/x}  else  e2{v/x}.  From  the  typing  of  e,  we  know 
T ,x'-T',y-  ({ Xi  ■  Ti}r)w;pc';li  h  ei  :  By  the  induction  hypothesis,  we 

have  T,y:  ({x^  :  Ti}r)w;  pc' ;  T-L  t-  ei{v/x}  :  r",  Af.  From  this,  (3.3),  and  (3.4), 
the  result  holds  in  this  case  via  an  application  of  T-EXISTS: 

T;  pc;  T-L  h  m{v/x}  :  (soft  {a:* :  Ti}r)w,  T 
h-  auth+(r)  ^  pcnw  w'  =  auth_(r)  n  persist(r)  n  tc 
r ,y-({xi :  Ti}r)w',pcl]'H  H  ei{v/x}  :  r'',  A, 

T;  pc';  t-  e2{v/x}  ■  r",  X2  I-  auth+(r")  =>  pc' 

T;pc]'H  i-  exists  u{v/x}  as  y  :  ei{v/x}  else  e2{v/x}  ■  r"  n  w',  Ai  n  A2 . 

Case  T-Let  (e  =  let  y  =  e\  in  e2): 

From  the  typing  of  e,  we  have 

T,x'-r']pc]'H  ei  ■■  Ti,Xi  \-  auth+(ri)  ^  pc  w  =  (n^o n  integ(ri) 

pc'  =  pcnw  T,x:T,,y:ri;pc'\'H  t-  e2  :  r2,  A2  i- auth+ (r2)  pc' 

r, x:t'; pc;  i-  let  y  =  ei  in  e2  :  r2  n  w,  Ax  n  X2  , 

where  r  =  r2 n tc  and  X  =  XxnX2.  By  the  induction  hypothesis,  we  therefore 
have 

T-,pc]'H  i-  ei{v/x}  ■■  ri,  X\.  (3.5) 

Suppose  y  =  x.  Then  e{v/x}  =  let  x  =  ex{v/x}  in  e2,  so  from  (3.5),  the  result 
holds  in  this  case  via  an  application  of  T-LET: 

T;  pc;T-L  ei{v/x}  ■■  tx,  Xx  f-  auth+  (ly)  =>  pc  w  -  (11  *0 n  integ(ri) 

pc' =  pc  nw  r,y:ri;pc'-'H\-  e2:r2,X2  f- auth+(r2)  «  pc' 

T;  pc;  h  let  y  =  ei{v/x}  in  e2  :  r2  n  w,  X1  n  X2 


105 


Alternatively,  suppose  y  *  x.  We  have  FV(c)  =  0,  so  e{v/x}  =  let  y  = 
ei{v/x]  in  e2{v/x}.  From  the  typing  of  e,  we  know  T,  x  :r',y :  Ti,pc']PL  \- 
e2  :  t2,  X2.  By  the  induction  hypothesis,  we  have  T,  y :  ri;  pc';  PL  e2{v/x}  : 
t2,X2.  From  this  and  (3.5),  the  result  holds  in  this  case  via  an  application 
of  T-LET: 

r ;  pc;  PL  \-  ei{v/x}  ■  T\,  X\  y-  auth+(Ti)  =>  pc  w  =  (11  *0 n  integ(ri) 
pc' =  pen  w  T,  y:Ti,pc';H  e2{v/x}  :  t2,  X2  \-  auth+(r2)  pc' 

h  let  y  -  ei{v/x}  in  e2{v/x}  :  r2  nw,X1n  X2 


□ 

Lemma  7  (Effect  bound).  The  effect  of  a  well-typed  expression  is  bounded  from  below 
by  its  handler  environment. 


r ;  pc;  PL  e  ’■  t,  X  =^PL  ^  X 

Proof  By  induction  on  the  derivation  of  T;  pc;  h  e  :  r,  A.  Rule  T-Try  relies  on 
the  easily  proved  fact  that  if  PL  u  {p}  4  Xlr  then  PL  =?  X\ /p.  □ 

Lemma  8  (Value  typing).  The  handler  environment  is  irrelevant  for  typing  non¬ 
bottom  values.  Such  a  value  v  can  also  be  typed  with  any  pc  that  has  the  authority 
of  the  references  that  appear  in  v,  and  can  have  any  effect  bounded  from  below  by  the 
handler  environment.  Formally, 

T]  pc-.PL  v  ■■  t,  X  a  (Vp.  v  +  _LP  a  v  ±  [ip]) 
a  h  auth+(r)  =>  pc'  a  \-PL’  4  X' 

=>  T;  pc';  PL'  v  :  r,  X' 

Proof.  By  induction  on  the  derivation  of  T;  pc\PL  v  ■■  r,  X .  □ 

We  are  now  ready  to  prove  type  preservation  for  [A persist]- 
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Lemma  9  (Type  preservation).  Let  M  be  a  well-formed  memory.  Let  e  be  an  expres¬ 
sion  with  type  t  and  effect  X.  Let  a  e  C.  If  the  configuration  (e,M)  takes  an  -+Q 
transition,  then  the  new  expression  e'  will  also  have  type  r  and  effect  X: 

M  a  0;  pc;  LL  e  '■  t,  X 
A  {e,  M)  a  (e',Mr) 

=>  0;  pc;  H\ -  e' :  t,X. 

Proof  By  induction  on  the  derivation  of  0;  pc;  'LL  i-  e  :  t,  X. 

Given  (e,  M)  -+a  (e',  M'),  the  proof  proceeds  by  cases  according  to  the  evalu¬ 
ation  rules.  For  cases  GC,  u-CREATE,  a- ASSIGN,  and  a-FORGET,  we  have  e  =  e' , 
so  the  result  follows  trivially 
By  Lemma  7,  we  have  Li  =?  X. 

Case  CREATE  (({ay  -  v'i}s,M )  -*-a  | ms,M[ms  fix,  =  where  m  is  fresh, 

S  =  {Xi :  Ti}(a,p),  and  v[  =  v%  rfi: 

We  have  0;pc;H  i-  {xi  -  v]}s  :  RT,  T  with  f?  =  {ay :  Tj}(ajaiP)  and  S'  : 

rectype.  We  need  to  show  0;pc;Li  t-  ms  :  .Rt,T-  This  is  given  by  trivial 
application  of  T-LOC. 

Case  APPLY  (((A(x:ri)[pc1;  H{\.  efi)  v,  M)  (ei{v/x},  XI)): 

From  the  typing  of  e,  we  have 

f  1 2 

0;  pc;  Li  i—  A(x:Ti)[pc1;'Hi].ei :  (n  >  t)T)t  (3.6) 


and 


0;pc;Li  H  v  :  T1;  T 


(3.7) 


with  i -  H  3  Hi  and  =  A.  We  need  to  show  0;pc;Li  ei{v/x}  :  r, Li\. 
From  the  derivation  of  (3.6),  we  know 


x'-T^pcy,  H\  i-  ei  :  r,7fi 
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with  h  pc1  4  pc.  Applying  Corollary  5  to  this,  we  get 


x:Ti;pc]'H  i-  e\  :  t,  'Hi. 

The  result  follows  from  this  and  (3.7)  via  Lemma  6. 

Case  SELECT  ((ms.xc,  M)  -+a  (vc  >ap,M),  where  M(ms)  =  {xi  =  c)}  and  S  = 

{ Xi  •  Tj} (a,p)  )• 

We  have  0;  pc;  "H  i-  ms.xc  :  rc  n  p,p  and  need  to  show  0;  pc;  H  \-  vc  >ap  ■■ 

rcnp,p. 

From  the  typing  of  e,  we  know  0;  pc;  H  t-  m5, :  ({xj :  rj}(aja)P))T,  T  and  h -  a  4 
pc  with  \-wf  S  :  rectype.  Therefore,  the  following  holds: 

•  h  a uth+ (rc)  =$  a  4  pc  and 

•  h  auth+(rc)  =>  p. 

So,  we  know  i-  a  uth+ (rc)  ^  pc  n  p. 

By  Lemma  7,  we  have  i -  H  4  p.  Since  M  is  well-formed,  we  also  know  that 
0;  T;  T  h  vc  :  rc,  T,  so  by  Lemma  8,  we  have 

0;pc  np;7f  h  r>c  :  rc,p.  (3.8) 

Suppose  ha^port)c  is  bracketed.  Then  vc  >a  p  -  vc  and  the  result  follows 
from  (3.8)  via  Corollary  5  and  T-SUBSUME. 

Otherwise,  a  $  p  and  vc  is  unbracketed.  So  vc  >a  p  -  [vc],  and  the  result 
follows  via  T-BRACKET: 

0;  pc  n  p;  h  r>c  :  rc,p  a^  p  h  auth+ (rc)  ^  pc  n  p 
0;pc;7f  h  [vc]  :  rcnp,p 
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Case  DANGLE-SELECT  (( m3.xc ,  M)  -+a  (ip  p,  M),  where  M ( ms )  =  1  and  S  = 

{*C  •  Tj} ( a,p )  )• 

We  have  0;  pc; TL  t-  ms.xc  :  rc  n  p,p  and  need  to  show  0;  pc;  "H  h  ip  >a  p  : 

rcnp,p. 

From  the  typing  of  e,  we  know  0;  pc;  H  h  ms  :  ({ Xi  ■  T;}(a,a,P)) T,  T  and  h  a  4 
pc  with  f-jrf  S  ■  rectype.  Therefore,  the  following  holds: 

•  h  a uth+ (rc)  =»  a  4  pc  and 

•  h  auth+(rc)  =?  p. 

So,  we  know  h-  a  uth+ (rc)  4  pen  p. 

By  Lemma  7,  we  know  i-  H  ^  p,  so  by  T-BOTTOM,  we  have 

0;pc  np;7f  h-  _Lp  :  Tc,p.  (3.9) 

Suppose  h  a  =?  p.  Then  lp  p  =  lp  and  the  result  follows  from  (3.8)  via 
Corollary  5  and  T-SUBSUME. 

Otherwise,  a  $  p.  So  ip  >a  p  -  [lp],  and  the  result  follows  via  T-BRACKET: 

0; pc  n p; h  ip  :  rc,p  a^p  h- auth+ (rc)  =>  pc  n  p 
0;pc;7f  h  [ip]  :  rcnp,p 

Case  Soft-Select  (((soft  ms).xc,M)  ->a  (v  ►„  (anp),M),  where  S  = 
{Xi  ■  Ti}(a,p)  and  (ms.xc,M)  4  (v,M)): 

From  the  typing  of  e,  we  have  0;pc;7f  t-  (soft  ms).xc  :  rc  n  p',p  and 
h  auth+(rc)  =?  pc,  where  p'  -  a  n  p.  So  r  =  rc  n  p'  and  X  =  p.  We  need  to 
show  0;pc;7f  h  v  >ap' :  rc  np',p. 
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From  the  typing  of  e,  it  follows  that  \-wf  S  :  rectype,  and  therefore,  we  know 
h  auth+(rc)  ^  p'.  Since  we  also  know  i-  auth+(rc)  ^  pc,  we  therefore  have 
h-  auth+(rc)  =?  pc  n  p' . 

We  proceed  by  cases  according  to  the  evaluation  rules  for  (ms.xc,M)  A- 
(v,M). 

Sub-case  SELECT  ((ms .xc,  M)  A-  (vc  >ap,M),  where  M(ms )  =  {x,  -  ty}): 
We  have  v  -  vc  >a  p. 

By  Lemma  7,  we  have  h  H  4  p.  Since  M  is  well-formed,  we  also  know 
that  0;  T;  T  i-  vc  :  tc,  T,  so  by  Lemma  8,  we  have 

0;pc  np';7f  h  vc  :  rc,p.  (3.10) 

Suppose  i-  a  ^  p'.  Then  h  a  ^  p,  so  v  >a p'  =  v  =  vc>ap  =  vc.  Similarly,  if 
vc  is  bracketed,  then  v  ►„//  =  vc.  In  these  cases,  the  result  follows  from 
(3.10)  via  Corollary  5  and  T-SUBSUME. 

Otherwise,  a  $  p'  and  vc  is  unbracketed.  So  v  >ap'  =  [ty]  and  the  result 
follows  via  T-BRACKET: 

0;pc  rp']T-L  t-  uc  :  rc,p  a  £  p'  t-  auth+(rc)  ^  pc  n p' 
0-,pc-,'H\-[vc\:Tcr\p',p 

Sub-case  DANGLE-SELECT  ((- ms.xc,M )  —>  (ip  >ap,  M)): 

We  have  v  =  ip  >a  p. 

By  Lemma  7,  we  know  i -  H  4  p,  and  we  have  \-  p'  4  p  by  definition,  so 
by  T-BOTTOM,  we  have  0;  pc  n  p'\  H  i-  _LP  :  rc  n  p',p. 

Suppose  y-  a  4  p’ .  Then  i-  a  ^  p,  so  v  >a  p'  =  v  =  lp  *-ap  =  ip,  and  the 
result  follows  via  Corollary  5. 
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Otherwise,  a  $  //,  so  v  >a  p'  =  [_LP],  and  the  result  follows  via  T- 
BRACKET: 

0;pc  np'j'H  i-  lp  :  rc  np',p  a^p1  h  auth+(rc)  <  pc  np' 
0;pc;'H  h  [ip] :  rc  np',p 

Case  ASSIGN  ((ms.xc  ■=  v,M)  (*  >ap,  M[ms.xc  ^  v']),  where  S  = 

{Xi  •  Tj} (a,p)  )• 

From  the  typing  of  e,  we  have  0;  pc;  'H  h  ms.xc  :=  v  ■  l,p  and  need  to  show 
0;pc;  h  *  >aP-  1  ,P-  By  Lemma  7,  we  have  \- W  4  p,  so  from  T-UNIT  and 
T-SUBSUME,  we  have  0;  pc  np;  Ti  \-  *  :  l,p. 

If  h  a  p,  then  *  >-ap  =  *,  and  the  result  follows  by  Corollary  5. 

Otherwise,  a  $  p  and  *  ►„  p  =  [*],  and  the  result  follows  via  T-BRACKET. 

Case  DANGLE-ASSIGN  ((ms.xc  ■■=  v,  M)  -+a  (l p*-ap,M),  where  S 

{Xi  ■  Tj} ( a,p )  )• 

From  the  typing  of  e,  we  have  0;pc;7f  h  ms.xc  :=  v  :  1  ,p  and  we  need 
to  show  0;pc;7f  hi  p  >a  p  ■  1  ,p.  By  Lemma  7,  we  have  h  ^  p,  so  by 
T-BOTTOM,  we  have  0;pc  npj'H  h  ip  :  l,p. 

If  h  a  4  p,  then  lp  >a  P  =  lp,  and  the  result  follows  by  Corollary  5. 
Otherwise,  a  $  p  and  lp  ►a  p  =  [lp],  and  the  result  follows  via  T-BRACKET. 

Case  SOFT-ASSIGN  (((soft  ms).xc  ■■=  v,M)  -»-a  (tAa  (an p),M'),  where 
(ms.xc  :=  v ,  M)  (c',  M')  and  S  =  {xOh}(a,P)): 

From  the  typing  of  e,  we  have  0;pc;7f  h  (soft  ms).xc  :=  v  :  1  ,p.  By 
Lemma  7,  we  have  h  "H  p.  Let  p'  =  a  n  p.  We  need  to  show  0;  pc;  Ti  h 
v'  ►ap'  :  l,p.  We  proceed  by  cases  according  to  the  evaluation  rules  for 

(■ ms.xc  :=  v,  M)  (vr,  M'). 
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Sub-case  ASSIGN  (( ms.xc  :=  v,M)  (*  >-ap,M')): 

We  have  v'  =  *  ►a  p. 

If  i-  a  4  p',  then  h  a  4  p,  so  v'  p'  -  v'  -  *  ►„  p  -  *.  The  result  follows 
from  T-UNIT  and  T-SUBSUME. 

Otherwise,  a  £  p'r  so  v'  >ap'  =  [*].  The  result  follows  from  T-UNIT, 
T-BRACKET,  and  T-SUBSUME. 

Sub-case  DANGLE-ASSIGN  (( ms.xc  ■=  v,M)  A-  (ip  *-ap,M)): 

We  have  v'  =  lp  ►Q  p. 

If  i-  a  3  p' ,  then  i-  a  4  p,  so  v'  >ap'  =  v'  =  lp  >ap  =  lp.  The  result  follows 
from  T-BOTTOM. 

Otherwise,  a  £  //,  so  v'  >ap'  =  [_LP],  The  result  follows  from  T-BOTTOM 
and  T-BRACKET. 

Case  Exists-True  ((exists  soft  ms  as  x  ■  e±  else  e2,M)  ((ei{ ms/x})  w ,  M), 

where  S'  =  {xj :  r,}(ap)  and  w  =  anp): 

From  the  typing  of  e,  we  have 

0;  pc;  i- soft  m5  :  (soft  {a;, :  r,}(aja)P))T,  T  i- a  =>  pc  w-anp 
x-({xi :  '^}(o,a,p))T;Pc  nwA  i-ei :  t'vAi 
0;  pc  n  tc;  f-  e2  :  r',  A2  f-  auth+(r')  ^  pc  n  tc 

0;  pc;  h  exists  soft  m5  as  a: :  ei  else  e2  :  r'  n  w,  X\  n  X2 
where  r  -  t'  nw  and  X  =  X\  n  X2.  We  need  to  show 

0;  pc;  "H  f-  (ei{m5/a:})  >a  w  :  r,  A. 
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By  T-LOC,  we  have  0-1pcnw\'H  t-  ms  :  ({ :  Ti}(a,a,P))i,  T.  Therefore,  by 
Lemma  6,  we  know  0-,pcnw\'Hn  e\ {ms/x}  ■  r',  X\.  Also,  by  Lemma  7,  we 
know  i-  V,  s?  X\  n  A2,  so  by  T-SUBSUME,  we  know 

0;  pc  e\ {ms /x}  :  r,  A. 

Suppose  i -  a  4  w.  Then  (eijm^/x})  >aw  =  e\ {ms/x}.  The  result  therefore 
follows  by  Corollary  5. 

Otherwise,  we  have  a  ^  w,  so  (ei{ms/x})  >a  w  -  [ei{ ms/x}].  The  result 
therefore  follows  via  T-BRACKET: 

0;  pc  n  w,  H  h  ei{ms/x}  :  r'  n  w,  X  a^w  i-  auth+(r')  =>  pc  n  w 
0-,pc;'H  h-  [ei{ms/x}]  :  r'  ntc,  A 

Case  EXISTS-FALSE  ((exists  soft  m5  as  a; :  e\  else  e2,  M)  -+a  (e2  ►<*  w,  M),  where 
S  =  {Xi :  Ti}(a,p)  and  w  =  a  n  p): 

From  the  typing  of  e,  we  have 

0; pc; "H  i-  soft  m5  :  (soft  {a:, :  Tj}(ajaiP))T,  T  i -  a  4  pc  w  -  an p 

x-({xi :  Ti}^p))1]pcnw\'H  t-d  ■t,vX1 
0;  pc  n  tc;  h  e2  :  r',  <T2  h-  auth+(r')  =>  pc  n  tc 

0;  pc;  h  exists  soft  ms  as  x  :  ei  else  e2  :  r'  n  w,  W  n  A2 

where  r  =  r'  n  w  and  X  =  Xt  n  X2.  We  need  to  show  0;  pc;  H  h  e2  ►a  w  :  r,  A. 

Suppose  h-  a  ^  w.  Then  e2  ►Q  w  -  e2.  The  result  follows  from  Corollary  5 
and  T-SUBSUME. 

Otherwise,  a  vj,  so  e2  >aw  =  [e2].  By  Femma  7,  we  know  \-  H  4  Xx  n  X2. 
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The  result  follows  via  T-BRACKET  and  T-SUBSUME: 


0;  pc  n  w;  %  h  e2  '■  r',  X2  a^w  auth+(r')  =$  pc  n  w 

0;pc;'H  \-  [e2]  ■  r'  n  w,  X2 
4  X \nX2  hX1nX2*X2 

0;  pc;  T~L  i-  [e2]  -r'  nw,X1n  X2 

Case  Try-Val  ((try  v  catch  p:  e\ ,M)  -+a  (v,M),  where  v  ±  1  p>  and  v  ±  [l^]  for 
all  p'): 

From  the  typing  of  e,  we  have 

0;  pc;  H,p  h  v  ■  r,  Xlr 

for  some  X\.  Since  v  is  a  non-bottom  value,  the  result  0;pc;'H  t-  v  :  r, <T 
follows  via  Lemma  8. 

Case  TRY-CATCH  ((try  Ip  catch  p':  e2,M)  -*-a  (e2,  XI),  where  i-pC  p): 

We  have  p'  4  p,  so  from  the  typing  of  e,  we  have 

0;pcnpn  integ(ri); %  t-  e2  :  n, T\ 

where  r  =  Ty  n  p.  We  need  to  show  0;  pc;  H  h  e2  :  r,  T\  This  follows  from 
Corollary  5  and  T-SUBSUME. 

Case  TRY-ESC  ((try  Lp  catch  p'\  e2,  M)  ->Q  (ip,  XI),  where  p'  $  p): 

We  have  p'  £  p,  so  from  the  typing  of  e,  it  follows  that  'H  4  X  4  p.  We  need 
to  show  0;pc;H  4  Lp  ■■  t,  X.  This  follows  from  T-BOTTOM  and  T-SUBSUME. 

Case  Parallel-Result  ((vi\w2,M)  -»• a  (*, XI)): 

From  the  typing  of  e,  we  have  r  =  1  and  X  =  T.  The  result  0;pc;'H  i-  *  :  1,  T 
follows  trivially  from  T-UNIT. 
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Case  IF-TRUE  ((if  true  then  e\  else  e2),  M)  -+a  (e1:  M)): 

From  the  typing  of  e,  we  have  0;  pc;  H  \-  e\  :  r,  Al,  where  =?  ffi .  We  need 
to  show  0;  pc;  ei  :  t,  X ,  which  follows  from  Lemma  7  and  T-SUBSUME. 

Case  IF-FALSE  ((if  false  then  e\  else  e2,M)  ->a  (e2,M)): 

From  the  typing  of  e,  we  have  0;  pc;  H  i-  e2  :  r,  ff2/  where  =$  ff2.  We  need 
to  show  0;  pc;  h  e2  :  r,  A”,  which  follows  from  Lemma  7  and  T-SUBSUME. 

Case  LET  ((let  x  =  v  in  ei,  M)  -»-a  (ei{v/x},  M),  where  ^  {_LP,  [ip]}  for  all  p): 

Since  v  is  a  non-bottom  value,  by  Lemma  8,  it  can  be  typed  with  T  effect. 
From  the  typing  of  e,  then,  we  have 

0;pc;7f  h  v  ■  t±,T 


and 


x'-Ti;pcn  integ(ri);  %  i -  ei  :  t,  A”. 


We  need  to  show  0;  pc;  "H  t-  ei{v/x}  :  r,  A’,  which  follows  from  Corollary  5 
and  Lemma  6. 

Case  EVAL-CONTEXT  ((E\ei\,  M)  ->a  {E\e[],  M') ,  where  (e2 ,M)  —> 

We  need  to  show  0;  pc;  "H  h  C[e(  ]  :  r,  X.  We  proceed  by  cases  according  to 
the  structure  of  E[e{\. 


Case  soft  e\. 

From  the  typing  of  e,  we  have  0;pc;7f  \~  e\  :  RW,X,  where  r  = 
(soft  _R)W.  By  the  induction  hypothesis,  we  have  0;  pc;  "H  i-  e\  :  A”, 

so  the  result  follows  via  T-Soft. 
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Cases  6^1162  and 

We  show  case  ei  11  e2-  The  other  case  follows  symmetrically.  From  the 
typing  of  e,  we  have  0;  pc;  T  i-  ei  :  Ti,  T.  By  the  induction  hypothesis, 
we  have  0;  pc,  T  h  ej  :  Ti,  T,  so  the  result  follows  via  T-PARALLEL. 

Case  try  e\  catch  p:  e2: 

From  the  typing  of  e,  we  have  0;  pc,  H,p\-  e i  :  T\,XU  where  r  =  ri  n  w 
with  w  =  |  Ij/cA’i  (pup')  and  A”  =  (Xjp)  n  X-2.  By  the  induction  hypoth¬ 
esis,  we  have  0;  pc;  H,p  e\  :  ti,  Ah  so  the  result  follows  via  T-Try. 

Case  let  re  =  e\  in  e2: 

From  the  typing  of  e,  we  have  0;  pc;  %  i-  ei  :  T\,  X\,  where  f-  auth+(ri)  => 
pc  and  i-  X\  4  X.  By  the  induction  hypothesis,  we  have  0;  pc;  H  t-  e,\  : 
t i ,  A’j ,  so  the  result  follows  via  T-Let. 

Case  Fail-Prop  ((F[ip],M)  -»-a  (i P,M))\ 

We  have  0;pc;'H  e  :  t,X  and  need  to  show  0;pc;'H  t-  _LP  :  t,  W  From 
the  typing  of  e,  it  follows  that  \-'H4X4p±T,  so  the  result  follows  from 
T-BOTTOM  and  T-SUBSUME. 

Case  Bracket-Select  (([ms].xc,M)  {[ms.xc],  M))\ 

Without  loss  of  generality,  assume  S  =  {xt  ■  Ti}(a.p)-  Then,  from  the  typing 
of  e,  we  have 

0;  pcnw,7i  \-  ms  :  ({r c*  :  7^}(0,0,p))t,  T 
a  ^  w  a  4  pen  w 

0;pc;H  t-  [m5]  :  ({rc* :  Ti}(a,a,p))«;,T 
t-  a  =>  pc  w'  =  wnp  \ -  T-L  4  p 

0;  pc,  %  i-  [ms].xc  :  tc  n  w’,p  , 

where  r  =  rc  n  tc'  and  X  =  p.  We  need  to  show  0;pc;'H  t-  [ms.a;c]  :  rc  n  «/, p. 
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By  the  typing  of  ms,  we  know  \-wf  S  :  rectype,  and  so,  i-  auth+(rc)  4  a  4  pc  n 
w.  Therefore,  the  result  follows  from  an  application  of  T-SELECT,  followed 
by  T-BRACKET: 

0\pcnw\'H  h-  ms  :  {{xi  :  7^} (a,a,p)  )t>  T 
a  4  pen  w  i -V.  4  p 

0',pcnw]/H\-ms.xc'-Tcnp,p  a^w  \-  auth+(rc)  =>  pc  n  w 

0;  pc;  %  t-  [ms.xc\  :  rc  n  w',p 

Case  Bracket-Soft-Select  (([soft  ms].xc,M)  -+a  ([(soft  ms).xc],M))\ 

Without  loss  of  generality,  assume  S  =  {x^  ■  Ti}(a,P)-  Then,  from  the  typing 
of  e,  we  have 

0;pcnw;'Hh  soft  ms  :  (soft  {i“77y}((W)))T,  T 
a  ^  w  a  4  pen  w 

0]  pc  \  T~L  y-  [soft  ms] :  (soft  {x~T^}^a  ap))w,  j 
f-  auth+(rc)  =>  pc  w'-wnanp  i -%4p 

0;  pc;  %  t-  [soft  ms].xc  ■  rc  n  w',p  , 

where  r  =  rc  n  w'  and  X  =  p.  We  need  to  show  0;pc;T/  f-  [(soft  m5).a:c]  : 
rcnw',p. 

By  the  typing  of  m5,  we  know  i -wf  S  :  rectype,  and  so,  h  auth+(rc)  =>  a  4 
penw.  Therefore,  the  result  follows  from  T-SOFT-SELECT  and  T-BRACKET: 

0-,pcnw1'H\-  soft  ms  :  (soft  {T“77y}(aap))T,  t 
i—  auth+(Tc)  ^  pc  n  w  w'-wnanp  \ -  H  4  p 

0-,pcnw\'H\-  (soft  ms).xc :  rc  n  w',p 
a  £  w  i—  auth+(Tc)  ^  pc  n  w 

0;  pc;  H  i-  [(soft  ms).xc\  ■  tc  n  w’,p 
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Case  Bracket- Assign  (([ ms].xc  -.=  v,M)  -* a  ([ ms.xc  -.=  v],M)): 


Without  loss  of  generality,  assume  S  =  {xt :  Tj}(0jP).  Then,  from  the  typing 
of  e,  we  have 

0-1pcnw]U\-  ms :  ({x* :  Ti p))T,  T 

a  ^  w  a  4  pen  w 

0]pc-'H  h  [ms]  :  {{Xi :  Ti}(a,a,p))w,  T  h  a  «  pc  0]pc\H  v  :  r',  T 

h  r;  n  pc  n  ir  <  rc  i- auth+(r')  ^  pc  n  ru  i -  H  4  p 

0;pc;'H  [ms].xc:=  v- l,p  , 

where  r  =  1  and  A  =  p.  We  need  to  show  0;  pc;  Ti  \-  [ms.xc  :=  r]  :  l,p. 

From  i—  auth+(r')  ^  pc  n  tc  and  Lemma  8,  we  know  0;  pc  n  tc;  i-  r>  :  r',  T. 
The  result  then  follows  from  an  application  of  T- ASSIGN  followed  by  T- 
BRACKET: 

0-1pcnw1U\-  ms  :  ({T“7^}(a,a,p))T,T  t-  a  «  pc 
0]  pc  n  w,7i  v  ■  t\  T  h  r'  n  pc  n  tc  <  rc 
i-  auth+(r')  ^  pc  n  tc  \-W.4p 

0;pc  n  w;7i  i-  ms.xc  :=  v  ■  l,p  a  ^  tc 

0;  pc;  "H  i- [m5.xc  :=  v]  :  l,p 
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Case  Bracket-Soft-Assign 

(([soft  ms].xc  :=  v,M)  -*-a  ([(soft  ms).xc  :=  v],M)): 

Without  loss  of  generality,  assume  S  =  {ay  :  Then,  from  the  typing 

of  e,  we  have 

0;pcr\w;U\-  soft  m5  :  (soft  {icn}(a,«,P))T,T 
a  £  w  h  a  =$  pen  w 

0',pc;'H  I—  [soft  mS ]  :  (soft  {Xi  :  Ti}(a,a,p))w,T  0;pC\U  H  V  :  t',T 

i-  t'  n  pc  n  w  <  tc  i—  auth+(T/)  ^  pc  n  w  \ -  7i  4  p 

0;  pc;  H  i-  [soft  ms].xc  ■■=  v  ■  *,p  , 

where  r  =  1  and  A  =  p.  We  need  to  show  0;  pc;  H  [(soft  ms).xc  :=  v]  :  l,p. 

From  h-  auth+(r')  ^  pc  n  w  and  Lemma  8,  we  know  0; pc  r\  w;T-L  i-  v  :  r',  T. 
The  result  then  follows  from  T-SOFT- ASSIGN  and  T-BRACKET: 

0;pcnw;'H  soft  ms  :  (soft  {ay  :  Tj}(0jajP))T,  T  0;  pc  n  w;  H  I-  v  :  r,  T 
i-  r'  n  pc  n  w  <  tc  i-  auth+(r')  ^  pc  n  w  i -'H^p 

0;  pc  n  w;  H  h  (soft  ms).xc  :=  v  :  l,p 
a  ^  w 

0;  pc;  H  h  [(soft  ms).xc  :=  v]  :  l,p 

Case  Bracket-Soft  ((soft  [m5],M)  -»a  ([soft  ms],M)): 

Without  loss  of  generality,  assume  S'  =  {ay  :  r{}(aiP).  Then,  from  the  typing 
of  e,  we  have 

0;pcnw;'H  \-  ms  :  ({ay  :  r{}(a,a,p))T, T 
a  ^  w  a  ^  pen  w 

0;  pc;  H  [m5] :  ({5yT^}(aia)P)).u,,T 
0;pc;U  v-  soft  [m5]  :  (soft  {ay  :  7y}(a,a,p))™,  T, 


119 


where  r  =  (soft  {x^ :  Ti}(a,a,P))w  and  X  -  T.  We  need  to  show  0-pc;H  i- 
[soft  ms]  :  (soft  {xj :  Ti}(a,a,p))w,  T.  This  follows  via  an  application  of  T- 
SOFT  followed  by  T-BRACKET: 

0;  pc  n  w;  H  h  ms  :  ({T7T^}(a,a,P))T,  T 
0;  pc  n  w;  "H  i-  soft  m5  :  (soft  {a:*  :  Tj}(ai0)P))T,  T  a  ^  w 
0;  pc;  H  h  [soft  m5]  :  (soft  {x*  :  Tj}(aAP))UJ,  T 

Case  Bracket-Exists 

((exists  [c]  as  a; :  ei  else  e2,  M)  ([exists  v  as  a; :  ei  else  e2],M)): 

From  the  typing  of  e,  we  have 

0;  pc  n  i\  Ti  \-  v  ■  (soft  {re*  :  r* T 
a  $  t  h  auth+(r)  <  pc  n  t 

0',pc;'H  H  [v]  :  (soft  {Xi  :  Ti}r)w n«,T 
h-  auth+(r)  ^pcnwnf  «/  =  auth~(r)  n  persist(r)  nwnl 
a;:  ({Xj  :  ri}r)wne;pcnw,-,'H  e1  :r',A’1 
0;  pc  n  «/;  h  e2  :  t',  X2  h  auth+(r')  =>  pc  n  u/ 

0;  pc;  h  exists  [v]  as  x :  e1  else  e2  :  r'  n  w',  XY  n  X2 

where  r  =  r'  n  w'  and  X  -  X1  n  X2.  We  need  to  show  0;pc;7f  t- 
[exists  v  as  x  :  ei  else  e2]  :  r’  n  ?i;',  Xx  n  X2.  To  do  this,  we  need  to  know 
that  x  :  {{xi :  Tj}r)w;pc  n  i—  ei  :  r',Xi,  which  can  be  demonstrated 

by  an  easy  induction  on  the  derivation  of  a;  :  ({ x^  ■  Ti}r)wnf,pc  n  w'\H  h 
e\  :  r' .  ffi.  The  result  therefore  follows  via  an  application  of  T-EXISTS  and 
T-Bracket. 
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0; pen  i;T-L  v  '■  (soft  {xi  ■  Ti}r)w , T 
h  auth+(r)  4  pcnwni  w"  -  auth~(r)  n  persist(r)  n  w 
x  :  ({ Xi :  Ti}r)w ;  pen  in  w";  %\-  e\-  t\  X\ 

0]  pen  in  w";  Ti  e2  :  r',  X2  i-  auth+(r')  ^  jfcnf  nw" 

0;  pc  n  i;  T-i  exists  v  as  x  :  ei  else  e2  :  r'  n  w",  dA  n  df2 
«  ^  f  h  auth+(r'  n  w")  =>  pc  n  ^  n  w"  4  pc  n  i 

0;  pc;  T-L  h  [exists  v  as  x  :  ei  else  e2]  :  r'  n  wr,  Xx  n  df2 
(Note  that  w'  -  i  n  w ".) 

Case  Bracket- Apply 

({[X(x:T1)\pc1;'hi\.  ei\  v2,M)  -»•„  ([(A(x:ti)[^c1;  Hi],  ei)  d2],M)): 

From  the  typing  of  e,  we  have 

x:ti,  pep,  7^i  i—  ei  :  t',%1 

pCi.Wl 

I -Wf  (A - >  r  )T  :  type  pc14  penw 

0;pcnw;'H\-  \(x:Ti)[pc1;'Hi].ei  ■  {t\  P  lHi>  r')T,J 
a  £  w  i—  pcx  4  pc  nw 

0;pc;U  i—  [X(x:T1)[pcp'H1\.  :  (ti  t')w,t 

0;pc;'H  i-  v2  :  Ti,  T  i-pc^pcnw  i ~'H4'Hi 

0;  pc;7f  i-  [A(a::ri)[pc1;7fi].  ei]  u2  :  t'  n  w,Ui  , 

where  r  =  r'  n  w  and  A  =  T-L\.  We  need  to  show  0;pc;'H  [(A(x  : 

T])[pc1;'Ui\.  ei)  v2\  :  r'nw.'Hi. 

By  WT4,  from  h-Ky  (n  — — — »  t')t  :  type,  we  know  h  auth+(ri)  u  auth+(r')  => 
pc1.  Since  we  also  know  from  the  above  derivation  that  h  pc1  4  pen  w,  it 
therefore  follows  that 

i-  auth+(Ti)  ^  pc  n  w  (3.11) 
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and  h-  auth+(r')  ^  pcnw.  From  the  above  derivation,  we  also  have  0;  pc;  T-L  h 
v2  :  ri,  T.  Applying  Lemma  8  to  this  and  (3.11),  we  have  0-1pcnw\'H  h  v2  ■ 
ri,  T.  The  result  then  follows  from  an  application  of  T-APP  followed  by 
T-BRACKET: 

0-,pcr\w\'H  h  X(x:ri)[pc1\'Hi].  e-i :  (ri  P  1  ^x>  t')t,T 
0;pc  n  w;  %  i-  v2  ■  Ti,  T  h  pc1  4  pc  n  w  i 

0;pcnw;'H  t-  (A(a;:ri)[pc1;  Hi],  ei)  v2  :  t'.'Hi 
a^w  h  auth+(r')  =>  pc  n  w 

0]pc]'H  h  \(X(x:T1)\pc1]'hi].  ei)  v2]  ■  r'nw^'Hi 

Case  BRACKET-TRY  ((try  [v]  catch  p:  e2,  M)  -*-a  ([try  c  catch  p:  e2],  M)): 

From  the  typing  of  e,  we  have 

0;  pcr\£;H,p\-  v  ■  t' ,  X\ 
cr  ^  f  f- auth+ (r')  =>  pc  n  £ 

0;  pc;  "H. p  h  [v]  :  r' nf,Ai  tc  =  PI  (pup') 

p'eV] 

0;  pc  n  tc  n  i  nteg(r'  n  f);7f  h  e2  :  t'  n  f,  X2  \ —  auth  (t'  n  £)  ^  pc 

0;  pc;  h  try  p]  catch  p:  e2  :  r'  n  £  n  w,  (T’l/p)  n  X2  , 

where  T  =  T'n<nw  and  X  =  (X1/p)  n X2. 

We  need  to  show 

0;  pc;  "H  i—  [try  v  catch  p:  e2]  :  r'  n  £  n  w,  ( Xi/p )  n  A2. 

Note  that  integ(r'  n  £)  =  integ(r')  n  £  and  auth+(r')  =  auth+(r'  n  £)  = 
auth+(r'  n  £  n  tc).  The  result  then  follows  from  S3,  T-SUBSUME,  T-TRY, 
and  T-BRACKET: 
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f-  integ(r')  rW  =>  integ(r') 

0;  pc  n  £; %,p  v  :  r',  X1  h  t'  <  r'  n  l 

0;  pcn£]'H,p\-  v  :rr  n  £,  X\ 

w  =  n  (pup') 

p'eA'i 

0;pcnfnwn  integ(V  n  £);  H  e2  :  r’  n  £,  X2  i -  auth+(r'  n  £)  ^  pc  n  £ 

0;  pc  n  £;'H  \-  try  v  catch  p:  e2  ■■  t1  n  £  n  w ,  (Xi/p)  n  X2 
a^£  h  auth+(r'  n  £  n  w)  4  pc  n  £ 

0;  pc:  T~L  h  [try  v  catch  p:  e2]  :  r'  n  £  n  w ,  (Xi/p)  n  fF2 

Case  BRACKET-lF  ((if  [v]  then  ei  else  e2,M)  ->Q  ([if  v  then  ei  else  e2],M)): 

From  the  typing  of  e,  we  have 

0;  pc  n  £;  H  h  v  :  booC,  T  QjJf 
0:pC]T-L  H  [v]  :  boolurrf,T 

0;  pc  n  w  n  £;  "H  h  e*  :  t',  X%  h  auth+(r')  =>  pc  n  w  n  £ 

0;  pc;  "H  h  if  [c]  then  ei  else  e2  :  r'  n  w  n  £,  X\  n  X2  , 

where  r  =  r'  n  w  n  £  and  X  -  X1  n  X2.  We  need  to  show  0;pc;'H  t- 
[if  v  then  e\  else  e2]  :  t'  n  w  n  £,  X\  n  X2. 

Since  auth+(r'  n  w)  -  auth+(r')  and  h  pc  n  w  n  £  4  pc  n  £,  we  therefore  have 
f-  auth+(r'  n  w)  4  pen £.  The  result  then  follows  from  T-If  and  T-BRACKET: 

0;  pc  n  £;%  v  :  bool„,,  T 

0;  pc  n  £  n  w;  H  h  e*  :  t',  Xt  h  auth+(r')  4  pen  £nw 

0;  pc  n  £;  'H  h  if  v  then  ei  else  e2  :  r'  n  w,  X\  n  X2 
a^£  h  auth+(r'  n  w)  4  pc  n  £ 

0;  pc;  H  [if  v  then  e\  else  e2]  :  r'  n  w  n  £,  Xt  n  X2 
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Case  BRACKET-LET  ((let  x  =  [v]  in  e\ ,M)  -+a  ([ei {[v]/x}],M),  where  v  +  lp  for 
all  p): 

By  Lemma  8,  we  know  [v]  can  be  typed  with  T  effect.  Therefore,  from  the 
typing  of  e,  we  have 

0;  pc  n  t\  7i  H  v  :  t",  T 
a  £  i  i-  auth+(r")  =$  pc  n  i 

0;  pc;  H  h  [r>]  :  r"  n  £,  T  f-  auth+(r"  n  (!)  4  pc 

w  -  integ(r"  n  i)  x:t"  n  pc  n  w\  H  f-  e\  :  r',  A”  h  auth+(r')  =>  pc  n  tc 

0;  pc;  h  let  x  =  [r>]  in  ei  :  r'  n  w,  X  , 

where  r  =  r'  n  w.  We  need  to  show  0;  pc;7f  h  [ei{[v]/x}]  :  t'  n  w,  X. 

From  the  derivation  above,  we  know  0;pc;7t  t-  [c]  :  t"  n  L  T.  Since 
auth+(r"  r  t)  -  auth+(r"),  from  h  auth+(r")  ^  pc  n  f  above,  we  have 
i-  auth+(r"  n  i)  4  pc  n  £.  Therefore,  by  Lemma  8,  we  know 

0]pcn£;H\-\v\:T"n£,T.  (3.12) 

From  the  derivation  above,  we  also  know  x'-r"  n  £\  pc  n  w;  H  e\  :  r',  X.  By 
definition,  h  w  4  i,  so  by  Corollary  5,  we  know  a;:r"n£;  pcnf;7t  h  e\ :  r',  X. 
Applying  Lemma  6  to  this  and  (3.12),  we  have 

0;  pc  n  f;  h  e\ {[v]/x}  ■  r'  n  w,  X . 

Since  auth+(r'ntc)  =  auth+(r')  and  i-  w  =$  £,  from  i-  auth+(r')  ^  pcnw  above, 
we  have 

h-  auth+(r'  n  w)  4  pc  n  l. 

Finally,  by  Lemma  7,  we  have  3  X. 
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The  result,  then,  follows  from  T-SUBSUME  and  T-BRACKET: 


0;  pc  n  t\ H  h-  e\{\v\lx}  ■  r'  n  w,  X 

h -H*X 

0;pcn£]'H\- ei{[v]/x}  :t' nw,X  t-  auth+(r'  n  w)  4  pc  n  £ 

0;pc-,'H  [ei{[v]/x}]  ■■  t' nw  n£,X 

Case  Double-Bracket  (([[v]],  M)  -+a  ([v],M)): 

From  the  typing  of  e,  we  have 

0;  pen  £\'H  \v]  ■■  t' ,  X  a^£  i-  auth+(V)  pc  n  £ 

0;pc;'H  [[v]]  :  r'  n£,  X  , 

where  r  =  r' n£.  We  need  to  show  0;  pc ;  H  h-  [r>]  :  r'n£,  X.  By  Corollary  5,  we 
know  0;  pc;  %  i-  [v]  :  r',  T\  The  result  then  follows  via  S3  and  T-SUBSUME: 

h-  integ(r')  n  i  =?  integ(r') 

0;  pc;  "H  i—  [c]  :  t'  ,  X  hr'<r'nf 

0;  pc;  h  [r>]  :  t'  n  £,  X 

Case  Bracket-Context  (([ei ],M)  {[e[],M')f  where  (euM)  -+a  (e[,  M'))\ 

From  the  typing  of  e,  we  have 

0;  pc  n  h  ei  :  r',  X  a^£  auth+ (V)  =>  pc  n  £ 

0;  pc;  h  [ei]  :  F  n  f ,  T  , 

where  t  -t'  n£.  We  need  to  show  0;  pc;  V.  \-  [e',  ]  :  r,  X. 

By  the  induction  hypothesis,  we  have  0;pc  n  £\T-L  i-  e'x  :  t',T\  The  result 
follows  by  T-BRACKET: 

0;pcnf;^he'1:r',T  a^£  i-  auth+ (r')  =>  pc  n  £ 

0;pc;%  i-  [e^]  :  r'  n£,  X 
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Case  Bracket-Fail  ({F[[ip]],M)  -+a  ([i P],M)): 

We  need  to  show  0;  pc ;  H  f-  [lp]  :  r,  We  proceed  by  cases  according  to 
the  structure  of  F[[lp]]. 

Case  soft  [ip]: 

From  the  typing  of  e,  we  have 
p±  T  \-T-i^p 

0;  pc  n  w;  %  h  ip  :  i?T,p  a  ^  tc  h  auth+(f?T)  =>  pc  n  w 
0]pc]U  h  [lp]  : 

0\pc\'H,  i-  soft  [_Lp] :  (soft  R)w,p  , 

where  r  =  (soft  i?)w  and  X  -  p.  The  result  follows  via  T-BOTTOM  and 
T-BRACKET: 

p  +  T  \-H^  p 

0;  pc  n  tc;  "H  f-  ip  :  (soft  R)T,p 
a^w  h  auth+((soft  f?)T)  =$  pc  n  w 

0;pc;'H  i-  [ip] :  (soft  R)w,p 

Case  let  x  =  [ip]  in  e2: 

From  the  typing  of  e,  we  have 

p  +  T  h  T-L  ^  p 

0;  pc  n  £]  H  i-  lp  :  Ti,p  h  auth+(ri)  ^  pc  n  £ 

0;pc-,H  h  [ip] :  n  n  f,p 
h  auth+(ri  n  f)  =>  pc  w  -  p  n  integ(ri  n  t) 
x'-Ti  n  £]  pc  n  w;  T-L  i-  e2  :  r2,  W  i-  auth+(r2)  ^  pc  n  w 

0;  pc;  H  let  x  =  [_LP]  in  e2  :  r2  ntc,,T2  np  , 
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where  r  =  r2  n  w  and  X  -  X2  n  p.  By  construction,  h  w  4  i,  so  we  know 
a  $  w.  By  Lemma  7,  we  also  know  h  H  4  X2  np.  The  result  follows  via 
T-BOTTOM,  T-Bracket  and  T-SUBSUME: 

p  +  T  v-H^p 

0\ pc  n  w,H  Ip  :  r2,p 
a  ^  w  f-  auth+(r2)  ^  pc  n  w 

0;pc-,'H\-  [ip]  :  r2  n  w,  p  t-  PL  ^  X2  n  p  i-  X2np  4  X2 

0;pc;'H\-[lp]:T2nw,X2np 


□ 


We  now  show  that  well-formedness  is  also  preserved  during  execution. 

Lemma  10  (Well-formedness  preservation).  If  (e,  M)  is  a  well-formed  configuration 
wherein  e  is  well-typed,  and  (e,  M)  takes  an  ->a  transition,  then  the  new  configuration 
(e’,  M')  will  also  be  well-formed: 

^[zvf]  (e> M)  A  0!  PC’  K  H  e  :  T,  X  A  (e,  M)  «  (e',  M')  (e',  M') . 

Proof  First,  note  that  dom(M)  £  dom(M').  This  can  be  shown  by  an  easy  induc¬ 
tion  on  the  derivation  of  (e,  M)  -»-a  ( e' ,  M'). 

We  prove  the  lemma  by  induction  on  the  derivation  of  (e,  M)  ->0  (e',M'). 
Given  (e,M)  ->q,  (e',Mr),  the  proof  proceeds  by  cases  according  to  the  evalua¬ 
tion  rules. 

Rules  Dangle-Select,  Dangle-Assign,  Parallel-Result,  Try-Esc, 
FAIL-PROP,  and  Bracket-Fail,  are  trivial  base  cases  in  which  locs(e')  =  0  and 
M'  =  M.  Rules  SELECT,  and  Soft-Select  follow  from  the  definition  of  i-j*^  M. 

Rules  Apply,  Exists-True,  Exists-False,  Try-Val,  Try-Catch,  If-True, 
If-False,  Let,  Bracket-Select,  Bracket-Soft-Select,  Bracket- Assign, 
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Bracket-Soft-Assign,  Bracket-Soft,  Bracket-Exists,  Bracket-Apply, 
Bracket-Try,  Bracket-If,  Bracket-Let,  and  Double-Bracket  follow  be¬ 
cause  in  these  cases,  locs(e')  £  locs(e),  M'  =  M,  and  root (ms,  e')  =>•  root(ms,  e). 

Rule  GC  follows  from  the  fact  that  \-?  n  M  and  that  minimal  collectible 
groups  must  be  disjoint. 

Rules  a- Create  and  a- Assign  follow  trivially  from  the  transition  rules. 
Rule  a-FORGET  follows  from  the  fact  that  n  M. 

[wf] 

Case  CREATE  (({ Xi  -  v'i}s ,  M)  -*-a  (ms,M\ms  { Xi  =  vt  >a  T;}]),  where  ms  is 
fresh  and  S  =  {x^ :  r,:}s): 

We  show  0;  T;  T  i -  Vi  -  r,.  T  for  arbitrary  i;  the  rest  of  this  case  follows  from 

From  the  typing  of  e,  we  have  0:  pc:  V.  \-  vt  :  r,,  T.  From  this,  the  result 
follows  via  Lemma  8  and  T-BRACKET. 

Case  ASSIGN  ({ms.xc:=v,M)  -*a  (*  *ap,  M[ms  i->-  v  tc]),  where  S  = 

{ Xi  •  Tj} (a,p))- 

From  the  typing  of  e  and  by  T-SUBSUME,  we  have  0;  pc;  H  v  ■  rc,  T.  By 
Lemma  8,  we  have  0;  T;  T  i-  v  ■  rc,  T,  and  the  rest  of  this  case  follows  from 

^[ufi 

Case  SOFT-ASSIGN  (((soft  ms).xc  ••=  v,M)  -+a  (v'  *-a  (anp),M'),  where 

(ms.xc  :=  v ,  M)  A-  (v',  M')  and  S  =  {xi :  7^}(a,p)): 

If  M(ms )  =  1,  then  we  have  locs(e')  =  0  and  M'  =  M,  and  the  result  fol¬ 
lows. 

Otherwise,  M(ms )  ^  1,  so  from  the  definition  of  ((soft  ms).xc  :=  v,  M), 

we  can  obtain  i-j*^  (ms.xc  :=  v,M),  and  the  rest  follows  similarly  to  the 
previous  case. 
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Case  EVAL-CONTEXT  (( E[ei],M )  -*-a  (E^],  M'},  where  (ei ,M)  A-  (e[,M')): 

Since  i-j*^  (e,  M),  we  know  (ei ,M).  Proceeding  by  cases  according  to 
the  structure  of  E\e{],  in  each  case  we  have  0;  pep  PC  i-  e\  :  Ti,  TI  (for  some 
pcj,  "Hi,  T\,  and  Xf).  So,  by  the  induction  hypothesis,  we  have  (e[,  M'). 
From  this  and  the  fact  that  i-j*^  (e,  M),  the  result  follows. 

Case  Bracket-Context  (([ei ],M)  ([e'J,M'),  where  {euM)  A-  (e[,M')): 

Since  (e,M),  we  know  i-"^  ( e\,M ).  From  the  typing  of  e,  we  have 
0;  pc';  H  e\  ■■  Ti,X,  for  some  appropriate  pc'  and  Ti.  So,  by  the  induction 
hypothesis,  we  have  1-“^  (e', ,  M'),  and  therefore  (e',  M'). 

□ 

Corollary  11  (Preservation). 

(c  M )  A  0;  pc;  ft  h  e  :  r,  A”  a  (e,  M)  ->■*  (e',  M') 

(e'> M')  A  0;  Pc;  y^e':r,X 

Proof.  This  follows  from  Femmas  9  and  10  by  induction  on  the  number  of  ->a 
transitions  taken.  □ 

Corollary  12  (Preservation  (non-adversarial  execution)). 

( e ,  M)  A0-1pc]'U\-  e:r,X  a  (e,  M)  ->*  (e',  M') 

=>i-[a)/]  (e',  M')  a  0;  pc;  TL\-e'  :t,X 

Proof.  This  follows  by  Corollary  11  and  the  definition  of  1 ~[wf\  ( e ,  M).  □ 

Lemma  13  (Progress).  Let  (e,  M)  be  a  configuration  wherein  e  has  type  r  and  effect 
X,  and  the  locations  appearing  in  e  are  mapped  by  M.  Then  either  e  is  a  value,  or  (e,  M) 
can  take  an  A-  transition: 

0;  pc;  h  e  :  r,  T”  a  locs(e)  £  dom(M) 

=>  e  is  a  value  v  3e',  ML  (e,  M)  —>■  (e',  M') 

(Doubly  bracketed  values  are  considered  expressions  and  not  values.) 
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Proof.  By  induction  on  the  derivation  of  0;  pc;  H  e  :  r,  X.  We  proceed  by  cases 
according  to  the  syntax  of  e.  Note  that  since  e  is  typed  in  an  empty  type  context 
(r  =  0),  we  must  have  FV(e)  =  0. 

Case  e  =  v: 

Trivial  since  e  is  a  value. 

Case  e  =  v\  v2: 

From  the  typing  of  e,  we  know  that  v\  is  a  value  with  an  arrow  type  and  T 
effect,  so  it  is  either  an  abstraction  X(x:ri)\pc1\'Hi\.  e±  or  a  bracketed  value 
[y[],  In  the  former  case,  by  APPLY,  we  have 

(e,M)  =  ((A(x:r1)[pc1;'Hi].e1)  v2,M)  ^  (ei{v2/ x} ,  M) . 

In  the  latter  case,  by  BRACKET- APPLY,  we  have  ( e,M )  -  ([v[]  v2 ,M)  —> 
(K  v2\,M). 

Case  e  =  if  V\  then  e2  else  e3: 

From  the  typing  of  e,  we  know  that  v\  is  a  value  with  bool  type  and  T  ef¬ 
fect,  so  either  Vi  =  true,  v\  =  false,  or  V\  is  a  bracketed  value  [v[].  If  Vi  =  true, 
then  by  IF-TRUE,  we  have  (e,  M)  =  (if  true  then  e2  else  e3,  M)  (e2,  M).  If 
V\  =  false,  then  by  IF-FALSE,  we  have  (e,  M)  -  (if  false  then  e2  else  e3,  M)  A- 
(e3,M).  Otherwise,  v\  =  [u(]  and  by  BRACKET-lF,  we  have  (e,  M)  = 
(if  [v(]  then  e2  else  e3,M)  A-  ([if  v\  then  e2  else  e3],M). 

Case  e  =  {xi  =  i^}s: 

Trivial  by  CREATE. 

Case  e  =  v.xc : 

From  the  typing  of  e,  we  know  v  is  a  value  with  record  type  and  T  effect,  so 
it  is  either  a  bracketed  hard  reference  (v  =  [ ms ]),  a  bracketed  soft  reference 
(v  =  [soft  ms ]),  a  hard  reference  (v  =  ms),  or  a  soft  reference  (v  =  soft  rns). 
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In  the  first  case  (v  =  [/n5]),  by  BRACKET-SELECT,  we  have  (e,M)  = 
([ms].xc,M)  A-  ([ ms.xc],M ).  In  the  second  case  (v  =  [soft  msl\), 
by  Bracket-Soft-Select,  we  have  (e,M)  =  ([soft  ms].xc, M)  A- 
([(soft  ms).xc\,  M). 

In  the  third  (v  =  ms)  and  fourth  (v  =  soft  ms )  cases,  assume  without  loss 
of  generality  S  =  {xi  ■  Ti }(a,P)-  Since  locs(e)  c  dom(M),  we  must  have  ms  € 
dom(M).  There  are  two  sub-cases  to  consider.  In  each  sub-case,  we  will 
show  ( ms.xc,M )  A-  (v",M),  for  some  v" ,  thereby  proving  the  case  of  a 
hard  reference  (v  =  ms).  The  case  of  a  soft  reference  (v  =  soft  ms)  follows 
by  Soft-Select:  ((soft  ms).xc,M)  4  (v"  ►<*  ( anp),M ). 

1.  Case  M(ms)  +  l: 

Without  loss  of  generality,  assume  M(ms)  =  {xt  =  ?;(} .  Then,  by  SE¬ 
LECT, 

(ms.xc,  M)  4  (dc  p,  M) . 

2.  Case  M(ms)  =  l: 

By  DANGLE-SELECT,  ( ms.xclM )  4  (lp  *-ap,M). 

Case  e  =  v.xc  v 

From  the  typing  of  e,  we  know  that  u  is  a  value  with  record  type  and  T  ef¬ 
fect,  so  it  must  be  either  a  bracketed  hard  reference  (v  =  [ ms ]),  a  bracketed 
soft  reference  (v  =  [soft  rris} ),  a  hard  reference  (v  -  rris),  or  a  soft  reference 
(v  =  soft  ms). 

In  the  first  case  (v  =  [ ms ]),  by  BRACKET-ASSIGN,  we  have  (e,M)  = 
([ ms].xc  v',M)  A-  ([/ns.a:c 

In  the  second  case  (v  =  [soft  ms ]),  by  BRACKET-SOFT- ASSIGN,  we  have 
( e,M )  =  ([soft  ms].xc  :=  v\  M)  A-  ([(soft  ms).xc:=v'],M). 
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For  the  remaining  cases,  suppose  v  =  ms  or  v  =  soft  ms.  Then,  since 
locs(e)  c  dom(M),  we  must  have  ms  e  dom(M).  Without  loss  of  gener¬ 
ality,  assume  S  =  {xi :  rJ(aiP).  From  the  typing  of  e,  we  also  know  that  v' 
is  a  value  with  T  effect,  so  v'  *  ip  and  v'  ±  [lr/]  for  all  p'.  There  are  two 
sub-cases  to  consider.  In  each  sub-case,  we  will  show  ( ms.xc  :=  v',M)  A- 
( v"',M '),  for  some  v'"  and  some  M',  thereby  proving  the  case  of  a  hard 
reference  (v  =  ms).  The  case  of  a  soft  reference  (v  =  soft  rns)  follows  by 
Soft- Assign:  ((soft  ms).xc  -.=  v',M)  4  (v'"  *-a  (a  np),M'). 

1.  Case  M(ms)  *  l: 

Without  loss  of  generality,  assume  M(ms )  =  {xt  =  ?.'(} .  Then,  by  AS¬ 
SIGN, 

^ms .xc  v1,  M )  A-  ►ap,  M[m,s'.a:c  t/  rc]) . 

2.  Case  M(ms)  =  1: 

By  DANGLE-ASSIGN,  {ms.xc  :=  v',M)  4  (lp  *ap,M). 

Case  e  =  exists  as  x  ■  e±  else  e2: 

From  the  typing  of  e,  we  know  that  is  a  value  with  soft  reference  type, 
so  it  is  either  a  bracketed  value  (v  =  [r/])  or  a  soft  reference  (v  =  soft  ms). 

In  the  first  case  (v  =  [i/]),  by  BRACKET-EXISTS,  we  have 

(e,  M)  =  (exists  [r/]  as  x  ■  e\  else  e2,M)  A-  ([exists  v'  as  x  ■  e\  else  e2],  M) 

The  second  case  (v  =  soft  ms)  splits  into  two  sub-cases.  Assume  S  = 
{a  :  Ti}(aiP)  without  loss  of  generality.  If  M  ( ms )  ±  1,  then  by  EXISTS-TRUE, 
we  have 

(e,  M)  =  (exists  soft  rns  as  x  :  ei  else  e2,  M)  A-  ((ei {ms /x})  >a  (a  n p),  M) 
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Otherwise,  M (ms)  =  1,  and  by  EXISTS-FALSE,  we  have 

(e,  M)  =  (exists  soft  ms  as  x  :  e\  else  e2,  M)  A-  (e2  ►„  (a  n  p ),  M) 

Case  e  =  soft  ei: 

From  the  typing  of  e,  we  know  that  0;pc;R  h  ei  :  RW,X,  where  r  = 
(soft  f?)w.  Since  locs(e)  £  dom(M),  we  must  also  have  locs(ei)  c  dom(M), 
so  by  the  induction  hypothesis,  either  e\  is  a  value  or  (ei,  M)  A-  (e\ ,  M'), 
for  some  e(  and  M' .  There  are  four  cases  to  consider: 

1.  ei  is  a  value  ip, 

2.  ei  is  a  bracketed  value  [v], 

3.  ei  is  some  other  value,  and 

4.  (e1,M)4(e'1,M'). 

In  case  1,  by  FAIL-PROP,  we  have  (e,  M)  =  (soft  ip,  M)  A-  (ip)  M). 

In  case  2,  by  BRACKET-SOFT,  we  have  (e,M)  =  (soft  [v],M)  —>■  ([soft  t>],  M). 
In  case  3,  e\  must  be  a  hard  reference  ms ,  so  e  =  soft  ms  is  also  a  value. 

In  case  4,  by  EVAL-CONTEXT,  we  have  (e,  M)  =  (soft  e\ ,M)  (soft  e\ ,  M'). 
Case  e  =  eiiie2: 

From  the  typing  of  e,  we  have  0;pc;T  h-  e,  :  r,,  T  for  i  e  {1,2}.  Since 
locs(e)  £  dom(M),  we  must  also  have  locs(e;)  £  dom(M),  so  by  the  in¬ 
duction  hypothesis,  either  e\  and  e2  are  both  values,  or  (without  loss  of 
generality)  (ei,  M)  A-  (e\ ,  M'),  for  some  e\  and  M'. 

If  e\  and  e2  are  both  values,  then  by  PARALLEL-RESULT,  we  have  (e,  M)  = 

(epi  e2,M)4(*,M). 

Otherwise,  by  EVAL-CONTEXT,  we  have  (e,M)  =  (ei  n e2,M)  (e[ne2,M'). 
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Case  e  =  try  eL  catch  p:  e2: 

From  the  typing  of  e,  we  have  0;  pc]  7-L,p\-  e±  :  r, .  A’!,  where  r  =  r,  n  w  with 
w  =  rip'eA',  (p  up').  Since  locs(e)  £  dom(M),  we  must  also  have  locs(ei)  £ 
dom(M),  so  by  the  induction  hypothesis,  either  e\  is  a  value  or  (ei,  M) 
{e'1,M'),  for  some  e[  and  M'.  There  are  five  cases  to  consider: 

1.  ei  is  a  value  lpr  and  i-  p  4  p' , 

2.  ei  is  a  value  lp>  and  p  ^  p' , 

3.  e\  is  a  bracketed  value  [c], 

4.  e\  is  some  other  value  v,  and 

5.  (e1,M)4(e'1,M'). 

In  case  1,  by  TRY-CATCH,  we  have  (e,M)  =  (try  _Lp/  catch  p:  e2,  M)  A- 
(e2,M). 

In  case  2,  by  TRY-ESC,  we  have  (e,  M)  =  (try  Lp  catch  p:  e2,M)4(V,M). 

In  case  3,  by  BRACKET-TRY,  we  have  (e,M)  =  (try  [r:]  catch  p:  e2,M)  A- 
([try  v  catch  p:  e2],M). 

In  case  4,  by  TRY-VAL,  we  have  (e,  M)  =  (try  v  catch  p:  e2,M)^(v,M). 
Finally,  in  case  5,  by  EVAL-CONTEXT,  we  have 

(e,  M)  =  (try  e-y  catch  p:  e2,  M)  (try  e\  catch  p:  e2,  M') 

Case  e  -  let  x  -  ey  in  e2: 

From  the  typing  of  e,  we  have  0;  pc,  H  i-  ey :  Ty,  Xy.  Since  locs(e)  £  dom(M), 
we  must  also  have  locs(ei)  £  dom(M),  so  by  the  induction  hypothesis, 
either  ey  is  a  value  or  (ey,M)  ( e'x,M'),  for  some  e[  and  M'.  There  are 
five  cases  to  consider: 
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1.  ei  is  a  bottom  value  ±p, 

2.  e\  is  a  bracketed  bottom  value  [ip], 

3.  ei  is  some  other  bracketed  value  [/■], 

4.  ei  is  some  other  value  v,  and 

5.  (e1,M)4(e'1,M'). 

In  case  1,  by  Fail-Prop,  we  have  (e,  M)  =  (let  x  =  Lp  in 

In  case  2,  by  BRACKET-FAIL,  we  have  (e,M)  -  (\et  x  =  [lp]  in  e2,M)  —>■ 
([lP],  M). 

In  case  3,  by  BRACKET-LET,  we  have  (e,M)  =  (letx=  [r>]  ine2,M)  A- 
(M[v]/x}],M). 

In  case  4,  by  LET,  we  have  (e,  M)  =  (let  x  -  v  in  e2,M)^(e2{v/x},M). 

In  case  5,  by  EVAL-CONTEXT,  we  have  (e,M)  =  (letx  =  ei  in  e2,M)  A- 
(let  x  =  e(  in  e2,  M'). 

Case  e  =  [e']: 

From  the  typing  of  e,  we  have  0;  pc' ;  H  e’  ■  r',  X.  Since  locs(e)  £  dom(M), 
we  must  also  have  locs(e')  c  dom(M),  so  by  the  induction  hypothesis,  ei¬ 
ther  e'  is  a  value  or  (er,  M)  (e",  M'). 

If  e'  is  a  bracketed  value  \v\,  then  by  DOUBLE-BRACKET,  we  have  (e,  M)  = 
([[v]],M)^([v],M). 

If  e'  is  some  other  value  v,  then  e  =  [r;]  is  a  value. 

Otherwise,  by  BRACKET-CONTEXT,  we  have  (e,M)  =  ([e'],M)  A- 

([e"],M'). 

□ 
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Corollary  14  (Soundness  of  [Aper,sxsi]). 

'-[■wfl  (e> M)  A  0;  pc]  n  I-  e  :  T,  A 

=>  (e,  M)  f[  v3v  €  Val,  Mr.  (e,  M)  —S  ( v ,  M') 

Proof.  This  follows  from  Corollary  11  and  Lemma  13  by  induction  on  the  num¬ 
ber  of  transitions  taken.  □ 

3.7.4  Limited  adversary  influence 

The  key  to  proving  both  referential  integrity  and  immunity  to  storage  attacks 
is  to  show  that  the  adversary  cannot  meaningfully  influence  the  high-integrity 
parts  of  the  program  and  memory.  This  property  is  similar  to  noninterfer¬ 
ence  [29],  and  similarly  can  be  expressed  using  an  equivalence  relation  on  con¬ 
figurations.  Two  configurations  are  equivalent  if  they  agree  on  all  high-integrity 
parts  of  the  program  and  of  the  memory. 

The  property  states  that  for  any  execution  influenced  by  the  adversary,  there 
is  a  corresponding,  equivalent  execution  in  which  the  adversary  is  not  present. 
Hence,  the  adversary's  influence  is  not  significant.  More  precisely,  each  config¬ 
uration  (ei,  Mi)  reached  via  the  language  augmented  by  adversarial  transitions 
must  be  equivalent  to  some  configuration  (e2,M2)  reachable  by  purely  non- 
adversarial  execution.  This  is  a  possibilistic  security  property,  which  is  prob¬ 
lematic  for  confidentiality  properties  [70],  but  is  acceptable  for  integrity. 

Because  the  two  executions  being  compared  operate  on  different  heaps,  with 
the  adversary  behaving  differently  in  the  two  executions,  the  addresses  cho¬ 
sen  when  records  are  allocated  may  differ.  However,  the  structure  of  the  high- 
integrity  part  of  the  heap  should  still  correspond.  A  homomorphism  f  is  used  to 
relate  corresponding  locations  in  the  two  heaps  that  are  high-integrity  or  high- 
persistence. 
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Definition  11  (High-integrity  homomorphism).  An  injective  partial  function  0  : 
dom(Mi)  ->■  dom(M2)  is  a  high-integrity  homomorphism  from  Mi  to  M2  if  it 
satisfies  the  following: 

•  Injective:  rnf  ±  m f2  a  {rnf 1 ,  mf2 }  £  dom(0)  =>  0(mf ' )  *  fjmtj2); 

•  Type-preserving:  mf2  =  =>  Sx  =  S2;  and 

•  Isomorphous  when  the  domain  and  range  are  restricted  to  the  high-integrity  and 
high-persistence  locations  in  Mi  and  M2: 

f  In  -D**R, 

where  D  =  {m5  €  dom(Mi)  ha^  integ(S')v  h  a  =>  persist(S')}  and  R  =  {m5,  e 
dom(M2)  |  h  a  =>  integ(S')v  h-  a  ^  persist(S')}.  The  notation  integ(S')  denotes 
the  integrity  of  a  record  with  type  S:  the  least  upper  bound  of  its  fields'  integrity. 

integ({a:j :  Ti}s )  =  □  integ(ri) 

i 

We  are  now  ready  to  define  our  notion  of  expression  equivalence.  The  ex¬ 
pression  ei  is  considered  to  be  equivalent  to  e2  via  a  high-integrity  homomor¬ 
phism  0,  written  0(ei)  e2/  if  ei  is  equal  to  e2  (modulo  bracketed  expressions) 

when  the  memory  locations  in  ei  are  transformed  via  0.  This  is  defined  formally 
in  Figure  3.12. 

To  ensure  that  high-integrity  dereferences  yield  equivalent  results,  we  also 
define  an  equivalence  relation  on  memories:  Mi  and  M2  are  equivalent  via  0, 
written  0(Mi)  &a  M2,  if  whenever  rns  e  dom(0)  is  not  deleted,  then  0(m5)  maps 
to  an  equivalent  record.  We  also  require  that  if  rns  e  dom(0)  is  a  deleted  high- 


137 


HX) 


X 


b  e  {true,  false} 

Hb)  ~Q  b 
He)  *a  e 


H*) 


Hjn f)  =  rnj 

Hm  1  )  m2 


d(A(x:r)[pc;?t].e)  * 

'■a  X(x'-t)[pc;'H].  e 1 

-Lp 

d(fi)  *4 (Vl) 

Hei)  ~ a 

p'  (v*) 

P(v  1  U2)  X2 

c/>(if  e\  then  e2  else  63)  ? 

if  e{  then  e2  else  63 

d(^)  *4 (Vl) 

Hv)  * a  V 

*a  -u' (v*) 

H{xi  =  =  Vi}5 

Hv-x)  *ot  v' -X 

Hvi-X  :=  'C2)  :=  v. 

He)  ~a  e 

Hei)  *>a  e'i  (Vi) 

d(soft  e)  RiQ  soft  e' 

Hie]) -a  [e'] 

0(ei ne2)  e'piea 

Hei)  ~a  e-  (vd 

^(exists  e\  as  x  :  e2  else  e 3)  fsa  exists  e}  ass  :  e2  else  e3 


Hei) 


JOL 


J  (Vi) 


Hei) 


JOL 


o'  (V*) 


^)(try  ei  catch  p:  e2)  try  e{  catch  p:  e2  <^( let  x  =  e\  in  e2)  xQ  let  x  =  e\  in  e2 


Figure  3.12:  Equivalence  of  expressions  in  [A persist\ 
authority,  high-persistence  location,  then  so  is  (p(rris).  Formally, 

def 

c i)(M\ )  M2  <=>•  Vms  e  dom(0). 

( Mi(ms )  1 1 

=>  M2(0(ms))  UA  0(Mi(m5))  rjq  M2(0(ms))) 
a  (h  a  ^  auth+(S')  n  persist(S')  a  Mi(ms)  =  1 
=>  M2(0(ms))  =  l) 

Together,  these  two  equivalence  definitions  induce  a  natural  equivalence  rela¬ 
tion  on  configurations: 

def 

Hei,  M])  os a  (e2,  M2)  <=>  0(ei)  e2  A0(Mi)  f»a  M2. 

A  [Apersjst]  program  has  limited  adversary  influence  if  equivalent  initial  config¬ 
urations  produce  equivalent  final  configurations. 

We  use  this  equivalence  relation  to  formalize  referential  integrity:  the  ad¬ 
versary  must  be  unable  to  cause  a  persistence  failure  in  the  high-integrity  parts 
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of  the  program  (expression  equivalence),  and  unable  to  cause  the  deletion  of 
high-authority,  high-persistence  objects  (memory  equivalence). 

3.7.5  Storage  attacks 

To  formalize  immunity  to  storage  attacks,  we  first  show  that  the  adversary  is 
unable  to  cause  more  high-persistence  locations  to  be  allocated.  This  is  captured 
by  the  equivalence  relation,  since  all  high-persistence  locations  are  mapped  by 
the  homomorphism. 

We  also  need  to  show  that  the  adversary  is  unable  to  cause  more  high- 
authority  locations  to  become  reachable  through  hard  references.  Lemma  20 
shows  that  this  is  implied  by  limited  adversary  influence. 

Lemma  15.  Let  e  be  well-typed  in  a  low-integrity  context.  Assume  that  ife  is  a  memory 
location,  then  it  is  low-authority.  If  rns  is  a  GC  root  in  e,  then  ms  must  be  low- 
authority: 

T; pc;?!  I-  e  :  r,  X  A  a  £  pc 

A(e  e  dom(M)  =>  a  auth+(r))  a  root(m5,e) 

=>  a  $  auth+(S') 

Proof.  By  induction  on  the  derivation  of  root (ms,  e ). 

Case  R1  (e  =  ms ): 

Without  loss  of  generality,  assume  S  =  {x, :  T,}(a,p),  where  a  £  a.  We  have 
t  =  ({ Xi :  T*}(a,a,p) )t/  so  auth+(r)  =  auth+(S')  and  the  result  follows  trivially. 

Case  R2  (e  =  soft  e',  where  Mmf .  e'  +  mf  ): 

From  the  derivation  of  root(ms,  e),  we  have  root(m5,  e').  From  the  typing 
of  e,  we  have  T:  pc:  'H  \-  e'  :  RW,X.  Therefore,  the  induction  hypothesis 
applies,  and  the  result  follows. 
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Case  R3  (e  =  {x,  =  i’i}s'): 

From  the  derivation  of  root(m5,  e),  we  have  root(ms,  vc)  for  some  c. 

From  the  typing  of  e,  we  know  T;  pc;  H  h  vc  ■  r',  T,  where  h  auth+(r')  ^  pc. 
From  this,  we  also  know  a  £  auth+(r'). 

Therefore,  the  induction  hypothesis  applies,  and  the  result  follows. 

Case  R4  (e  =  v.x ): 

From  the  derivation  of  root(ms,  e),  we  have  root(ms,  v). 

From  the  typing  of  e,  we  have  T;pc;?f  t-  v  :  r',  T,  where  either  t'  = 
({xi  ■  Ti}(a+,a-,p))w  with  \-  a+  4  pc,  or  t'  =  (soft  R)w  for  some  R.  We  therefore 
know  a  £  auth+(r'). 

Therefore,  the  induction  hypothesis  applies,  and  the  result  follows. 

Case  R5  (e  =  v\  .x  :=  v2): 

From  the  derivation  of  root(ms,  e),  we  have  root(ms,  v,),  for  some  i  €  {1,2}. 

From  the  typing  of  e,  we  know  T;pc;4/  t-  V\  :  r',  T  (where  either  r'  = 
({'Xi:  Ti}(a+:a-tP))w  with  h-  a+  4  pc,  or  t'  =  (soft  R)w  for  some  R)  and 
T;pc;?f  i-  v2  ■  t",  T,  where  h  auth+(r")  =>  pc.  Therefore,  a  ^  auth+(r')  and 
a  $  auth+(r").  So,  the  induction  hypothesis  applies  for  i  e  {1,2},  and  the 
result  follows. 

Case  R6  (e  =  A (x.r')\pc'\  R'].e'): 

From  the  typing  of  e,  we  know  i -wf  r  :  type,  i-  pc'  4  pc,  and  T,  x :  r';  pc';  W  v- 

pcf  H.r 

e'  :  t"  ,R' ,  where  r  =  t'  — • — >  r" .  Since  a  f  pc,  we  have  a  f  pc'.  From  \-wf 
r  :  type,  we  know  h-  auth+(r")  ^  pc',  so  we  therefore  know  a  auth+(r"). 
From  the  derivation  of  root(m5,  e),  we  know  root(ms,e').  Therefore,  the 
induction  hypothesis  applies,  and  the  result  follows. 
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Case  R 7  (e  =  v\  v2): 

From  the  derivation  of  root(ms,  e),  we  have  root(ms,  v,)  for  some  i  e  {1,2}. 

pcr 

From  the  typing  of  e,  we  know  T;  pc;  H  h  vx  :  (V  — : — >  t)w,  T,  T;  pc;  H  h  v2  • 

pc'  j'hL' 

r',  T,  and  (r'  — : — >  t)w  :  type,  with  h  pc'  4  pc.  Therefore,  a  f  pc'. 

pc'  ^H’ 

From  the  derivation  of  i -wf  (r'  — - — >  r)w  :  type,  we  have  i-  auth+(r')  =>  pc 
and  i-  auth+(r)  =>  pc.  We  therefore  know  a  £  auth+(r'). 

So,  the  induction  hypothesis  applies  for  i  e  { 1,2},  and  the  result  follows. 

Case  R8  (e  =  let  x  =  ex  in  e2): 

From  the  derivation  of  root(ms,  e),  we  have  root(ms,  e*),  for  some  i  e  {1,2}. 

From  the  typing  of  e,  we  know  T;  pc;  H  i—  ex  :  r',  X\  and  T,  x :  r';  pc';  W  e2: 
t",  X2,  where  h  auth+(r')  ^  pc,  pc’  -  pc  n  w,  and  h  auth+(r")  =>  pc',  for  some 
w.  Therefore,  it  follows  that  a  ^  pc',  a  $  auth+(r'),  and  a  $  auth+(r"). 

So,  the  induction  hypothesis  applies  for  i  e  { 1,2},  and  the  result  follows. 

Case  R9  (e  =  if  v  then  ex  else  e2): 

From  the  typing  of  e,  we  know  T;  pc;  "H  h-  c  :  boolw,  T  and  T;  pc  n  w;  H  \-  e*  : 
t',  X,  (for  i  e  {1, 2}),  where  h  auth+(r')  ^  pc.  From  this,  we  therefore  know 
a  £  auth+(r'). 

From  the  derivation  of  root(ms,e),  we  have  either  root(ms,v)  or 
root (ms,ej),  for  some  j  €  {1,2}.  In  all  cases,  the  induction  hypothesis 
applies,  and  the  result  follows. 

Case  RIO  (e  =  exists  v  as  x  :  e.\  else  e2 ): 

From  the  typing  of  e,  we  know  T;  pc;  i-  v  :  (soft  {xpp}r)w,  T  and  T*;  pc  n 
w'\  'H\ -  e*  :  r',T}  (for  i  e  {1, 2}),  where  t-  auth+(r')  ^  pc  n  w'.  From  this,  we 
therefore  know  a  ^  auth+(r'). 
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From  the  derivation  of  root(ms,e),  we  have  either  root(m,s',  v)  or 
root (ms,ej),  for  some  j  e  {1,2}.  In  all  cases,  the  induction  hypothesis 
applies,  and  the  result  follows. 

Case  Rll  (e  =  eiiie2): 

From  the  derivation  of  root(ms',  e),  we  have  root(ms,  e^)  for  some  i  e  {1,2}. 
Without  loss  of  generality,  assume  i  =  1. 

From  the  typing  of  e,  we  know  T;pc;T  f-  ex  :  ti,T  and  h-  auth+(ri)  ^  pc. 
From  this,  we  also  know  a  £  auth+(ri). 

Therefore,  the  induction  hypothesis  applies,  and  the  result  follows. 

Case  R12  (e  =  try  e±  catch  p:  e2): 

From  the  derivation  of  root(ms,  e),  we  have  root (ms,  e*),  for  some  i  e  {1,2}. 

From  the  typing  of  e,  we  know  T;pc;?f,p  t-  e1  :  t',Xi  and  T;pc';'H  \-  e2  : 
t',X2,  where  h  pc'  =>  pc  and  f-  auth+(r')  =>  pc.  From  this,  we  also  know 
a  $  pc'  and  a  $  auth+(r'). 

So,  the  induction  hypothesis  applies  for  i  e  { 1,2},  and  the  result  follows. 
Case  R13  (e  =  [e']): 

From  the  derivation  of  root(m5,  e),  we  have  root(ms,  e'). 

From  the  typing  of  e,  we  know  T;  pc';  H  h-  e'  :  r',  <T,  where  t-  pc'  =>  pc  and 
h  auth+(V)  ^  pc.  From  this,  it  follows  that  a  pc'  and  a  auth+(r'). 

Therefore,  the  induction  hypothesis  applies,  and  the  result  follows. 


□ 
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Lemma  16.  Let  d  and  e2  be  well-typed  expressions,  both  of  type  r,  that  are  equivalent 
via  a  high-integrity  homomorphism  0.  If  ms  is  a  high-authority  GC  root  in  e\,  then 
4>(ms)  is  also  a  GC  root  in  (e2,  Mf). 

T]  pc]'H  e\  ■■  t,  X  aT]  pc;'H  e2  '■  t,  X 
a  0(d)  e2A  h  a  auth+(5')  a  root(m5,  d) 

=>  root (0(m5),  e2) 

Proof  By  induction  on  the  derivation  of  root(m5,d).  The  proof  proceeds  by 
cases  according  to  the  syntax  of  d-  The  result  holds  vacuously  in  cases  d  =  x, 
e\  =  true,  e4  =  false,  d  =  *,  and  d  =  soft  mf1,  since  -.root(ms,  d)  in  these  cases. 

Case  d  =  rnf 1 : 

Since  root(m5,  mf 1 ),  we  must  have  mf1  =  ms.  Therefore,  from  0(d)  ~Q  e2, 
we  have  e2  =  0(rns),  and  the  result  follows  via  Rule  Rl. 

Case  d  =  e3: 

From  0(d)  e2,  we  have  e2  =  X(x  :  r')[pc';  7t'].  e4,  where  0(e3)  «a  e4. 

From  the  typing  of  e1  and  e2,  we  have  T,  x  ■  T';pc';'Hr  e3  :  t" ,W  and 
T,x:t';pc'\  W  h  e4  :  t" ,  for  some  pc',  H' ,  and  t" .  From  the  derivation  of 
root(ms,  d),  we  know  root(ms,  e3).  Therefore,  we  can  apply  the  induction 
hypothesis  to  obtain  root (0(ms'),  e4),  and  the  result  follows  via  Rule  R6. 

Case  d  =  v\v2: 

From  the  derivation  of  root (ms,  e4),  we  know  root(ms,  v4)  or  root(ms,  v2). 
Without  loss  of  generality,  assume  root(m5,r>i).  From  0(d)  e2,  we  have 

e2  =  v3  v4,  where  f{v\)  xa  v3.  From  the  typing  of  d  and  e2,  we  have 
T;pc]'H  h-  V\  :  t',  T  and  T;  pc;  PI  \~  v3  :  t',  T,  for  some  t'.  Therefore,  we  can 
apply  the  induction  hypothesis  to  obtain  root (0(m5), v4),  and  the  result 
follows  via  Rule  R7. 
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Case  ei  =  if  e3  then  e4  else  e5: 


From  the  derivation  of  root(ms, ei),  we  know  root (ms,ek)  for  some  k  e 
{3, 4, 5}.  From  0(ei)  e2/  we  have  e2  =  if  e'3  then  e'A  else  e'5,  where  0(ej)  e' 

for  i  e  {3, 4, 5}.  From  the  typing  of  e\  and  e2/  we  have  T ;  pc';  V.  t-  e*,  :  r',  <T' 
and  T ;  pc' ;  H  e'k:  r',  X’ ,  for  some  pc',  r',  and  X'.  Therefore,  we  can  apply 
the  induction  hypothesis  to  obtain  root and  the  result  follows 
via  Rule  R9. 

Case  e\  =  {xi  =  iii}Sl: 

From  the  derivation  of  root(ms,ei),  we  know  root (ms,vk)  for  some  k. 
From  0(ei)  rJq,  e2,  we  have  e2  =  {x^  =  u'i}Sl,  where  (j)(vt)  Ui  for  all  i.  From 
the  typing  of  e4  and  e2,  we  have  T;  pc;  V.  \-  :  r',  T  and  T;  pc;  H  h  ek  ■  r',  T, 

for  some  r'.  Therefore,  we  can  apply  the  induction  hypothesis  to  obtain 
root(0(ms),  «*;),  and  the  result  follows  via  Rule  R3. 

Case  e4  =  v.x: 

From  the  derivation  of  root(ms,  ei),  we  know  root (ms,v).  From  (f>(ei) 
e2,  we  have  e2  =  u.x,  where  <f>(v )  u.  From  the  typing  of  e{  and  e2,  we 
have  T; pc; H  i-  v  :  t\  T  and  Y\pc\l-L  u  ■■  t',  T,  for  some  r'.  Therefore,  we 
can  apply  the  induction  hypothesis  to  obtain  root and  the  result 
follows  via  Rule  R4. 

Case  e\  =  v\.x  c2: 

From  the  derivation  of  root(m5,ei),  we  know  root (ms,Vk)  for  some  k. 
From  (f)(e i)  «Q  e2,  we  have  e2  =  u\.x  :=  m2,  where  m*  for  i  e  {1,2}. 

From  the  typing  of  e1  and  e2,  we  have  T;pc;'H  i-  vk  :  r',T  and  T;pc;'H  h 
uk  :  t',  T,  for  some  r'.  Therefore,  we  can  apply  the  induction  hypothesis  to 
obtain  root (4>(ms),uk)r  and  the  result  follows  via  Rule  R5. 
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Case  ex  -  soft  e3: 


From  the  derivation  of  root(m5,  e4),  we  know  root(ms,  e3)  and  e3  is  not  a 
memory  location.  From  <p{e4)  <*a  e2/  we  have  e2  =  soft  e4,  where  0(e3)  »a  e4; 
therefore,  e4  is  not  a  memory  location.  From  the  typing  of  e4  and  e2,  we 
have  T;pc-,'H  e3  :  t',X  and  T;pc;?f  \-  e4  :  t',X,  for  some  r'.  Therefore, 
we  can  apply  the  induction  hypothesis  to  obtain  root (0(m5'),  e4),  and  the 
result  follows  via  Rule  R2. 

Case  e4  —  e3ne4; 

From  the  derivation  of  root(ms,  e4),  we  know  root(m5,  ek)  for  some  k  e 
{3,4}.  From  0(e4)  e2,  we  have  e2  =  e^ne^,  where  d(e,)  e'  for  i  €  {3,4}. 

From  the  typing  of  e4  and  e2,  we  have  T;pc;T  h  ek  :  r',T  and  r;pc;T  h 
e'k  :  r',  T,  for  some  r'.  Therefore,  we  can  apply  the  induction  hypothesis  to 
obtain  root(0(m5),  e}),  and  the  result  follows  via  Rule  Rll. 

Case  e4  =  exists  e3  as  x  :  e4  else  e5: 

From  the  derivation  of  root (ms,ei),  we  know  root (ms,ek)  for  some  k  e 
{3,4,5}.  From  0(e4)  e2,  we  have  e2  =  exists  e'3  as  x  ■  e'4  else  e{,  where 

0(ej)  e'  for  i  e  {3, 4, 5}.  From  the  typing  of  e4  and  e2,  we  have  T';  pc' ;  H  h 
efc  :  r',  X'  and  T';  pc' ;  H  \-  e'k-  t',  X' ,  for  some  T',  pc',  r'  and  AT  Therefore, 
we  can  apply  the  induction  hypothesis  to  obtain  root(©(ms),  e'k ),  and  the 
result  follows  via  Rule  RIO. 

Case  e\  -  let  x  =  e3  in  e4: 

From  the  derivation  of  root(ms,  e4),  we  know  root(m5,efc)  for  some  k  e 
{3,4}.  From  0(e4)  *a  e2,  we  have  e2  =  let  x  =  in  e4,  where  rjq  e'  for 
i  €  {3,4}.  From  the  typing  of  e4  and  e2,  we  have  T';  pc';  H  ek  :  r',  A”'  and 
T';  pc' ;  "H  h  e'fc  :  r',  A”',  for  some  T',  pc',  r',  and  X' .  Therefore,  we  can  apply 
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the  induction  hypothesis  to  obtain  root ((p(ms),e'k),  and  the  result  follows 
via  Rule  R8. 

Case  e\  =  try  e3  catch  p:  e4: 

From  the  derivation  of  root(ms,ei),  we  know  root(ms,efc)  for  some  k  e 
{3, 4}.  From  4>{ef)  e2/  we  have  e2  =  try  e'3  catch  p:  e'4,  where  0(e,:)  e'  for 

%  e  {3, 4}.  From  the  typing  of  e\  and  e2/  we  have  T ;  pc' ;  H  ek  •  t',  X '  and 
T ;  pc' ;  TL  i-  e'k  :  t',  X' ,  for  some  pc',  t' ,  and  X'.  Therefore,  we  can  apply  the 
induction  hypothesis  to  obtain  root(0(m5),  e'k),  and  the  result  follows  via 
Rule  R12. 

Case  e\  —  [63]- 

From  the  derivation  of  root (ms,  ei),  we  know  root(m5,  e3).  From  the  typ¬ 
ing  of  e\,  we  know  T;  pc  n  t ;  H  h  e3  :  r',  X  for  some  i  and  r’ ,  where  a  ^  £  and 
1-  auth+(r')  4  pc  n£.  Therefore,  by  Lemma  15,  we  must  have  a  $  auth+(S'), 
which  contradicts  the  assumption  h  a  4  auth+(5).  So,  this  case  holds  vac¬ 
uously 


□ 

Lemma  17.  Suppose  ms  is  a  high-authority  location  that  is  a  GC  root  in  the  well-typed 
value  v.  Then  v  must  have  high-authority  type. 

1-  a  4  auth+(S')  a  root (ms ,  v)  a  0;  T;  T  h-  v  :  r,  T 
h  a  4  auth+(r) 

Proof.  Since  root(m5,r’),  the  value  v  must  either  be  equal  to  ms,  be  a  lambda 
abstraction  \{x‘T)\pc]'H].  e,  or  be  a  bracketed  value  [?/]. 
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Case  v  =  ms : 


We  therefore  have  0;  T;  T  i-  ms  :  r,  T.  So  i-  auth+(S')  =?  auth+(r).  Therefore, 
h  a  =>  auth+(r),  as  desired. 

Case  v  =  X (x:r)\pc;  Tl\.  e: 

From  the  derivation  of  root(ms,  v),  we  have  root(m5,  e).  So,  we  must  have 

pc  '1~C 

r  =  Ti  — r2,  for  some  T\  and  some  r2.  Therefore,  auth+(r)  =  pc. 

Suppose  a  $  pc.  From  the  typing  of  v,  we  know  x :  rp,  pc]  TL  e  :  r2,  TL  and 

pc  '1~L 

i  wf  T\  — — >  r2  :  type.  Therefore,  we  also  know  h  auth+(r2)  pc,  and  hence, 
a  $  auth+(r2).  Since  root(ms,  e),  by  Lemma  15,  we  must  have  a  $  auth+(S'), 
a  contradiction.  So,  we  must  have  t-  a  3  pc  =  auth+(r),  as  desired. 

Case  v  =  [V]: 

From  the  derivation  of  root(ms  ,v),  we  have  root (ms,vr).  From  the  typing 
derivation  of  v,  we  know  0;f;Th  v' :  r',  T  and  h  auth+(V)  ^  l,  where  af£. 
Therefore,  a  auth+(r').  Since  root (ms ,v')r  by  Lemma  15,  we  must  have 
a  $  auth+(S'),  a  contradiction.  This  case  therefore  holds  vacuously. 

□ 

Lemma  18.  Suppose  ms  is  a  high-authority  location  that  is  non-collectible  in  the  con¬ 
figuration  ( v ,  M),  where  M  is  well-formed  and  the  value  v  has  type  r.  Then  r  must  be 
high-authority. 

^[wf]  h  a  ^  auth+(S)  a  uc(ms ,  (v,  M ))  a  0;  T;  T  h-  v  :  r,  T 
=>  h  a  4  auth+(r) 

Proof.  By  induction  on  the  derivation  of  nc(ms,  { v ,  M)). 

Case  NCI: 

We  have  root(m5,  v).  The  result  follows  via  Lemma  17. 
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Case  NC2: 


We  have  root(m,  ,v),  M (mf 1 )  =  {xi  =  v]},  and  n c(ms,{vc,M))  for  some 
c.  Without  loss  of  generality,  assume  Si  =  {x,  ■  T,}(aj)y  From  M,  we 
have  0;  t;  t  h  vc  :  tc,  T.  Therefore,  we  can  apply  the  induction  hypothesis 
to  obtain  \-  a  =>  auth+(rc).  From  M,  we  know  \-wf  S\  :  rectype,  and 
therefore,  h  auth+(rc)  =>  a.  Hence,  i-  a  4  a  =  auth+(S'i).  The  result  follows 
via  Lemma  17. 


□ 

Corollary  19.  Suppose  ms  is  a  high-authority  location  that  is  non-collectible  in  the 
configuration  where  M  is  well-formed.  Then  mf  is  high-integrity,  high- 

authority,  and  high-persistence. 

i M a  h  a  4  auth+(S')  a  nc(ms, 

=>  h  a  3  integ(S'i)  n  auth+(S'i)  n  persist(Si) 

Proof.  Since  i-j^  M,  we  must  have  \-uf  S\  :  rectype,  and  so,  h  auth+(S'i)  =? 
integ(S'i)  n  persist(S'i).  It  therefore  suffices  to  show  that  rnf  is  high-authority. 
This  follows  from  Lemma  18.  □ 
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We  now  show  that  limited  adversary  influence  is  sufficient  to  demonstrate 
immunity  to  storage  attacks. 

Lemma  20.  Let  (ei ,Mf)  be  a  well-formed  configuration,  wherein  ex  has  type  r.  Let 
(e2 ,M2),  wherein  e2  also  has  type  r,  be  a  configuration  that  is  well-formed  in  a  non- 
adversarial  setting.  Assume  the  two  configurations  are  equivalent  via  a  high-integrity 
homomorphism  f.  If  ms  is  a  high-authority  non-collectible  location  in  (ei,Mi),  then 
4>(ms)  is  also  non-collectible  in  (e2,  Mf). 

(ei,  Mf)  a  0;  pc-  U  h  ei  :  r,  X 
a  \-[wfl  M2  a  0;  pc ;  U\-e2-T,X 

a  cj)(e i,  Mi)  r sa  (e2,  M2)a  h  a  =>  auth+(S')  a  nc(m5,  (e^Mf)) 

=>  n c((f>(ms),(e2lM2)) 

Proof  By  induction  on  the  derivation  of  nc(ms,  (ei,  Mi)). 

Case  NCI: 

We  have  root(ms,  ei).  By  Lemma  16,  we  therefore  have  root ((j)(ms),e2), 
and  the  result  follows  by  NCI. 

Case  NC2: 

We  have  root(mf1,ei)  and  nc(ms,  (vc,  Mf))  for  some  mf,  where  M1(mf1)  = 
{xi  =  i>i}.  It  therefore  follows  that  nc  ^\wf\  (mf '  ,  M \ ),  and 

^[wfl 

Assume  m  f  *  ms.  (Otherwise,  we  would  have  root(m5,  ei),  and  the  argu¬ 
ment  for  Case  NCI  applies.) 

Since  ms  is  high-authority  and  nc (ms ,  (mf ,  Mf) ,  by  Corollary  19,  we 
know  mf1  is  high-integrity,  high-authority,  and  high-persistence. 
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Since  root(mf1,ei)  and  m^1  is  high-authority,  by  Lemma  16,  we  know 
root(0(mi1),e2). 

From  <f){ei,Mi )  &a  (e2,M2),  we  know  f(M\ )  M2.  So,  from  t  1, 

we  have  M2(f(mf1))  =  {a;*  =  u,},  where  0(vc)  itc,  for  some  vf. 

Since  i-j^  Mi  and  i-^  M2,  we  also  know  0;  T;  T  i-  vc  ■  rc,  T  and  0;  T;  T  f-  wc  : 
rc,  T,  for  some  rc.  Therefore,  we  can  apply  the  induction  hypothesis  to  get 
nc(0(m5),  (uc,  Mf)). 

The  result  follows  via  NC2. 


□ 


3.7.6  Referential  security 

Lemma  21.  Let  rns  be  part  of  a  group  G  that  is  collectible  in  (e,M).  If  ms  is  non¬ 
collectible  in  lrrii,M\,  then  mf1  must  also  be  in  G. 

gc(G,  (e,  M ))  a  ms  e  G  a  nc(ms,  (mf1,  M'))  =>  mf1  €  G 

Proof  By  induction  on  the  derivation  of  n c(ms ,  (mf1,  M)). 

Case  NCI: 

We  have  root(rns,  mf 1 ).  From  this,  it  follows  that  mf1  =  ms ,  and  the  result 
follows  trivially 

Case  NC2: 

We  have  M (mf1 )  =  {rc,  =  vf},  and  n c(ms,(vc,M))  for  some  c.  Suppose 
root  (mf2 ,  vc  )  for  some  mf2  e  G.  From  this,  we  know  root(mf2 ,  M (mf1)) , 
and  from  the  definition  of  gc(G,  (e,  M)),  we  have  mf1  e  G,  as  desired. 

We  proceed  by  cases  according  to  the  derivation  of  n c(ms,  ( vc ,  M ))  to  find 
such  an  mf2. 
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Case  NCI: 


We  have  root (ms ,vc),  so  choose  mf2  =  ms. 

Case  NC2: 

We  have  root(mf3,  vc),  M{m f3)  =  {xi  =  u,},  and  n c(ms ,  (uC',  M))  for 
some  m^3  and  some  c'.  It  therefore  follows  that  nc (ms,  [m33,  M)).  So, 
we  can  apply  the  induction  hypothesis  to  obtain  mf3  €  G.  Therefore, 
we  can  choose  m 2 2  =  mf3. 


□ 


Lemma  22.  All  locations  in  a  collectible  group  are  collectible: 

gc(G,  (e,  M ))  a  ms  eG=>  -inc(ms,  (e,  M)). 

Proof.  By  contradiction.  Let  ms  €  G  be  such  that  nc(ms',  (e,M)).  We  proceed  by 
cases  according  to  the  derivation  of  n c(ms ,  (e,M)). 

Case  NCI: 

We  have  root(ms,  e).  But  from  the  definition  of  gc(G,  (e,  M)),  no  such  m3 
can  exist;  a  contradiction. 

Case  NC2: 

We  have  root(mf1,e),  M (mf 1 )  =  {m,  =  v]},  and  n c(ms,(vc,M))  for  some 
c.  From  this,  it  follows  that  n c(ms Amf1 ,  M)).  Therefore,  by  Lemma  21, 
we  have  mf1  €  G.  So,  from  the  definition  of  g c(G,{e,M)),  we  have 
-.root(mf1,  e),  a  contradiction. 

□ 

Lemma  23.  Let  C  c  dom(M)  be  a  set  of  locations  that  are  collectible  in  a  configuration 
(e,  M): 

Mms  e  C.  -.n c(ms ,  ( e ,  M)). 
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Then  there  is  a  collectible  group  that  contains  C.  In  particular,  let  G  be  the  largest 
superset  of  C  such  that  from  every  location  in  G,  some  location  in  C  is  reachable  through 
a  chain  of  hard  references: 

Vmf°  €  G.  3-mf1  e  C.  n c(mf1,^mf°,M')).  (3.13) 

Then  G  is  a  collectible  group:  gc (G,  (e,  Ad)). 

Proof  Suppose  G  is  not  a  collectible  group.  Then  either  G  contains  a  GC  root  in 
e,  or  there  is  a  location  outside  G  with  a  hard  reference  into  G. 

Suppose  G  contains  a  GC  root  rns  in  e:  ms  e  G  a  root(m5,e).  By  construc¬ 
tion  of  G,  let  mf1  c  C  be  a  location  reachable  through  a  chain  of  hard  refer¬ 
ences  from  ms:  nc (mfl,(ms,M)).  If  Ad  (ms)  =  1,  then  from  the  derivation  of 
nc(mf1,  (ms ,M)),  we  must  have  ms  =  mf1,  and  so  from  root(ms,  e),  we  know 
nc(mf1,  ( e,M))r  a  contradiction.  Otherwise,  assume  M(ms )  *  1  and  ms  ±  mf1. 
Let  if  be  such  that  Ad(ms)  =  {xi  =  t^}.  From  the  derivation  of  nc(mf 1  ,  ( ms ,  Ad)), 
we  know  there  exists  a  c  such  that  nc(mf1,  {vc,  Ad)).  Therefore,  by  NC2,  we  have 
nc(mf1,  (e,M)),  a  contradiction. 

Otherwise,  let  ms  j.  G  be  such  that  Ad(ms)  has  a  hard  reference  to  some 
rnff  e  G:  root(mf°,M(ms)).  By  construction  of  G,  let  mf1  e  C  be  a  location 
reachable  through  a  chain  of  hard  references  from  mf°:  nc  (mf1,  (mf°,  A/)). 

We  presently  show  that  nc(mf1,  (M(ms),  Ad)).  If  M (rnff )  =  1,  then 
from  the  derivation  of  nc(mf1,(mo°;  M\),  we  must  have  mf°  =  mf1,  and  so 
from  root(mg°,  Ad(ms)),  we  know  nc(mf1,  (Ad(ms),  Ad)).  Otherwise,  assume 
M(mf°)  *  1  and  mf°  +  mf1.  Let  Tf  be  such  that  M (mff )  =  {xi  =  rf,}. 
From  the  derivation  of  nc(mf1,(mf°,  M)),  we  know  there  exists  a  c  such  that 
nc(mf1,  (vc,  Ad)).  Therefore,  by  NC2,  we  have  nc(mf1,  ( M(ms),M )). 

So,  we  know  nc(mf1,  (Ad(ms),M)).  It  therefore  follows  that  nc(mf1,  ( ms,M )). 
So,  G  u  {ms}  is  a  set  larger  than  G  satisfying  property  (3.13),  a  contradiction.  □ 
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Lemma  24.  Let  ex  and  e2  be  well-typed  equivalent  expressions,  and  suppose  &(/ns)  is 
a  high-authority  GC  root  of  e2.  Then  ms  is  a  GC  root  of  ex. 

4>{e i )  e2  a  T;  pc;  TL  ex  :r,X  a  T;  pc;  TL  e2  :  r,  A 

Aha^  auth+(S')  a  root  (f(ms),  e2) 

=>  root(ms,  ei) 

Proof.  By  induction  on  the  derivation  of  root(0(m5),  e2).  Since  e2  is  well-typed, 
by  Lemma  15,  we  know  that  case  R13  holds  vacuously  □ 

Lemma  25.  Suppose  M,  and  M2  are  well-formed  memories.  Let  &  be  a  high-integrity 
homomorphism  such  that  4>(MX)  psa  M2.  Let  ms  and  mf1  be  locations  in  Mx  mapped  by 
cf).  Assume  mf1  is  high-authority  and  high-persistence.  If  nc(0(mf1),  (<f)(ms),  M2)), 
then  nc(mf1,  ( ms ,  Mf)): 

h[wf]  -^2  A  f(Mx)  M2 

a  i-  a  auth+(Si)  n  persist(Si)  a  n c(0(m^1),  (cj)(ms),  M2)) 

=>  nc(mf1,  (m5,  Mi)). 

Proof.  By  induction  on  the  derivation  of  nc(0(mf1),  (0(m5),  Mf)). 

Case  NCI: 

We  must  have  ffms)  =  ^(mf1).  Since  f  is  injective,  we  know  ms  =  mf1,  so 
the  result  follows  by  NCI. 

Case  NC2: 

We  know  there  exists  some  tf,  and  some  c  such  that  M2{<j)(ms))  =  { x,  =  if } 
and  nc(0(mf1),  (mc,  M2)).  Assume  4>(ms)  +  ).  (Otherwise,  the 

argument  for  Case  NCI  applies.)  Since  ©(mf 1 )  is  high-authority  and 
nc(0(mf1),  (0(m5),M2)),  by  Corollary  19,  we  know  that  ms  is  high- 
integrity,  high-authority  and  high-persistence.  Since  4>{M\)  M2  and 
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M2((/)(ms ))  *  1,  then  we  must  have  M1(ms)  ±  1.  So  let  vr  be  such  that 

Mi(ms)  =  { Xi  -  v]}. 

We  show  that  nc(mf' ,  (vc,  Mi)).  From  this,  the  result  follows  via  an  appli¬ 
cation  of  NC2: 

root(m5,m5)  M\(rns)  =  {xt  =  v)}  nc(mf1,  (vc,  Mi)) 
nc(mf‘ ,  [m‘s,  Mi)). 

Consider  the  two  cases  in  the  derivation  of  n c(0(m^1),  (uc,  M2)): 

Sub-case  NCI: 

We  have  root From  4>{M\)  m a  M2/  we  know  4>{vc)  na 
uc.  From  i-j*^  Mi  and  1-“^  M2/  we  know  0;T;T  h  vc  :  rc,  T  and 
0;  T;  T  f-  uc  :  rc,  T,  for  some  rc.  Therefore,  we  can  apply  Lemma  24 
to  get  root(mf1,  vc),  and  the  result  follows  via  NCI. 

Sub-case  NC2: 

Assume  -.root(0(mf1),Mc).  (Otherwise,  the  argument  in  sub-case 
NCI  applies.) 

We  know  there  exists  some  rn22  €  dom(M2),  some  u)/  and  some  d  such 
that  root (m22,uc),  M2(m22)  =  {xi  =  u'i},  and  nc(0(mf1),  (u'c,,  M2)). 
From  this,  it  follows  that  nc(0(mf1),  (m22,  M2)).  Since  0(mf 1 )  is  high- 
authority  and  nc(0(mf1),  {m22 .  M2))r  by  Corollary  19,  we  know  that 
rn22  is  high-integrity,  high-authority,  and  high-persistence. 

Since  0  is  a  high-integrity  homomorphism,  there  exists  an  m^3  such 
that  ml2  =  0(777,3  ).  Therefore,  we  can  apply  the  induction  hypothesis 
to  get  nc(mf1, 

We  have  root(0(m33),wc).  From  0(Mi)  M2,  we  know  0(vc)  rsq 

uc.  From  Mi  and  i-j*^  M2/  we  know  0;T;T  h  vc  :  rc,  T  and 
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0;  T;  T  f-  uc  ■  rc,  T,  for  some  rc.  Therefore,  we  can  apply  Lemma  24 
to  get  root (mf3,vc). 

Since  mf2  =  from  -.root(0(mf1),wc)  and  root(m22,  wc), 

we  know  m 3 3  ^  mf 1 .  Therefore,  from  the  derivation  of 
nc(mf1,  (/nf3,Mi)),  we  know  there  exists  some  vt '  and  some  c"  such 
that  Mi{m f3)  =  {a;*  =  v[}  and  nc(mf1,  (vf,,  Mi)). 

The  result  follows  via  NC2: 

_ v 

root^mf3,^)  Mi(m f3)  =  {a;;  =  u'}  nc(mf1,  (u'»,  Mi)) 

nc(mf1,('uc,Mi)) 


□ 

Lemma  26.  Let  Gbea  collectible  group  in  (e,  M)  zezf/z  mf1  e  G.  If  nc (mf1 ,  (m5,  M)), 
f/zerz  m/s'  e  G: 


gc(G,  (e,  M))  a  mf 1  e  G  a  nc(mf1,  (m5,  M))  =>•  ms  e  G 

Proof.  By  induction  on  the  derivation  of  nc(mf 1 ,  (ms ,  M)). 

Case  NCI: 

We  must  have  rns  -  mf1,  so  the  result  follows  trivially 
Case  NC2: 

We  know  there  exists  some  if  and  some  c  such  that  M(ms )  =  {xt  =  z;f} 
and  nc(mf1,  (vc,  M)).  Consider  the  two  cases  in  the  derivation  of 

nc(mf1,  (vc,  M)): 

Sub-case  NCI: 

We  have  rootOmf1,  vc),  so  we  therefore  know  root(mf M(jns)).  The 
result  then  follows  from  the  definition  of  gc(G,  (e,  M)). 
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Sub-case  NC2: 


We  know  there  exists  some  location  m22  such  that  root  (mf2 ,  vc)  and 
nc(mf1,  So,  by  the  induction  hypothesis,  we  know  inf2  e 

G.  From  root(m:J2,  rv;),  we  know  roo^my2 ,  M(ms)).  The  result  then 
follows  from  the  definition  of  gc(G,  (e,  M)). 

□ 


Lemma  27.  Let  Mi  and  M2  be  well-formed  memories.  Suppose  0(ei,  Mi)  » >a  (e2,  M2). 
Let  G  be  a  collectible  group  in  ( ei,Mi ),  and  let  0(G)  denote  {f(ms)  :  m5,  e  G  n 
dom(0)}.  Let  C  represent  the  high-authority,  high-persistence  members  o/Gndom(0): 

C  =  {- ms  €  G  n  dom(0) :  ha^  auth+(S')  n  persist(S’)}. 

Then  there  exists  a  set  G'  such  that  0(G')  is  a  subset  of  0(G),  is  a  collectible  group  in 
(e2,  M2),  and  contains  all  members  o/0(C): 

*-[wf\  Mi  a  i- M2  a  0(ei,  Mi)  (e2,  M2)  a  gc(G,  (ei,  Mf)) 

=>  3 G'.  g ;c(0(G'),  (e2,  M2))  a  0(C)  c  0(G')  c  0(C) 

Proof.  First,  we  show  that  0(C)  is  a  set  of  collectible  locations.  Suppose  it 
isn't.  Then  let  ms  e  C  n  dom(0)  be  such  that  f(ms)  e  0(C)  is  non-collectible: 
nc(0(m5).  (e2,  M2)).  Since  0(m5)  is  high-authority  and  high-persistence,  by  in¬ 
duction  on  the  derivation  of  nc(0(ms'),  (e2,  M2)),  we  can  show  that  ms  must  be 
non-collectible:  nc(m5,  (ei,  Mi)).  Therefore,  by  Lemma  22,  C  cannot  be  a  col¬ 
lectible  group,  a  contradiction. 

Let  G'  L  dom(0)  be  such  that  0(G')  is  the  largest  superset  of  0(C)  such 
that  from  every  location  in  0(C'),  some  location  in  0(C)  is  reachable  through 
a  chain  of  hard  references:  'imff  €  0(G').  3-mf1  €  0(C).  nc(mf1,  (m^0,  M2)).  By 
Lemma  23,  we  know  0(G')  is  a  collectible  group. 
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We  now  show  that  f(G')  is  also  a  subset  of  f(G)  by  showing  G'  9  G.  Suppose 
rns  e  G'.  By  construction  of  G',  let  mf1  e  C  be  such  that  nc(0(mf1 ),  (ft(ms),  M2)). 
From  this,  by  Lemma  25,  we  know  nc(mf1,  ( ms ,  Mi)).  By  Lemma  26,  then,  we 
must  have  ms  <e  G.  So  G'  £  G.  □ 

Lemma  28  (Equivalence  substitution).  If  <p(ex)  e2  and  4>(e'ft  «a  eft  then 

f(ex {e'ftx})  *Q  e2{e'2/x}. 

Proof.  Simple  induction  on  the  derivation  of  0(ei)  e2.  □ 

Lemma  29  (Auto-bracketing  equivalence).  Auto-bracketing  preserves  equivalence: 

0(ei)  e2  =>  0(ei  >a  r)  e2  r. 

Lemma  30.  Suppose  0(ei)  e2.  Lef  m5  be  such  that  ms  /  locs(ei)  and  let  ft  - 

(f>[rns  mf].  Then  ft  (eft  e2. 

Lemma  31.  Evaluating  in  a  low-integrity  context  preserves  memory  equivalence. 

Let  (e1,M1)  be  a  well-formed  configuration,  wherein  e\  is  well-typed  in  a  low- 
integrity  context.  Let  M2  be  a  well-formed  memory  and  suppose  (ei,  Mft  A-*  (eft  Mft. 

(ex,  Mft  a  a  ^  pc  A0;pc;7f  f-  ei  :  r,  A 
Ahfiy/]M2A(e1,M1)^(e'1,M1'). 

Then  the  following  holds. 

1.  cj)(Mft  M2  =>  <f(M'ft  «a  M2  and 

2.  i -[w/\  (ex,  Mi)  a  0(M2)  Mi  =>  0(M2)  »a  Mf. 

Proof.  If  we  can  show  this  is  true  for  the  case  where  a  single  2+  step  is  taken, 
then  the  rest  follows  by  induction  on  the  number  of  2+  steps  taken.  (We  know 
the  induction  hypothesis  will  apply  because  of  Corollary  11  and  Corollary  12.) 
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We  show  the  single-step  case  by  induction  on  the  derivation  of  (e\, M\)  — »• 
(e[,M[).  The  proof  proceeds  by  cases  according  to  the  evaluation  rules. 

In  cases  Select,  Dangle-Select,  Soft-Select,  Dangle-Assign,  Ap¬ 
ply,  Exists-True,  Exists-False,  Try-Val,  Try-Catch,  Try-Esc,  Parallel- 
Result,  If-True,  If-False,  Let,  Fail-Prop,  Bracket-Select,  Bracket- 
Soft-Select,  Bracket-Assign,  Bracket-Soft-Assign,  Bracket-Soft, 
Bracket-Exists,  Bracket-Apply,  Bracket-Try,  Bracket-If,  Bracket- 
Let,  Double-Bracket,  and  Bracket-Fail,  the  result  holds  trivially,  since 
M[  =  Mx. 

Case  CREATE  ({{xi  =  v'i}s ,  Mi)  (ms,  Mi[ms  >a  r,}]),  where  m  is 

fresh  and  S  =  {x^Tn}(a,P))' 

1.  Suppose  M2.  We  show  that  M2. 

From  the  derivation  of  0;pc;'H  i-  e\  :  r,  X,  we  know  f-  p  4  pc  and 
t-  integ(rt)  =>  pc  for  all  i.  Therefore,  we  know  ms  is  neither  high- 
integrity  nor  high-persistence.  The  result  then  follows  from  the  fact 
that  ms  dom(0)  and  the  assumption  <p(M\ )  &a  M2. 

2.  Suppose  i ~[wf\  (ei,  Mi)  and  o{M2)  «Q  M1.  We  show  that  o{M2)  M[. 

This  follows  from  <p(M2)  Mx. 

Case  ASSIGN  ((ms.xc:=v,Mi)  (*  where 

Mi(ms)  1 1  and  S  = 

_ x 

Let  Vi'  and  u,  be  such  that  M[(ms )  =  {xi  =  v)}  and  M2(cj)(ms ))  =  {x,  =  Ui}. 
We  therefore  have  v'c  =  v  >a  rc. 

From  0;  pc;  "H  h  ms.xc  :=  v  :  r,  X,  we  know  h  r'  n  pc  <  rc,  for  some  r'.  We 
therefore  know  h-  integ(rc)  =>  pc.  So,  from  a  ^  pc,  we  have  a  1  integ(Tc). 
Therefore,  v'c  is  a  bracketed  value:  there  exists  a  v"  such  that  v'c  =  \y"\ 
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From  M2  and  a  £  integ(rc),  we  also  know  uc  is  a  bracketed  value: 
uc  =  [u'c],  for  some  u’c. 

1.  Suppose  o(M\ )  M2.  We  show  that  o(M[)  M2. 

Assume  ms  e  dom(©)  (otherwise,  the  result  follows  directly  from 
b(M, )  M2).  Since  0( M i)  M2,  it  suffices  to  show  0(c')  »a  uc. 
This  is  trivial,  since  v'  =  [?;"]  and  wc  =  [«']. 

2.  Suppose  h- [wy]  (ei,  Mi)  and  <f>(M2)  Mi.  We  show  that  (f>(M2)  xa  M[. 

Assume  ms  e  im(©)  (otherwise,  the  result  follows  directly  from 
(p(M2)  r ia  Mi).  Since  0(M2)  Mi,  it  suffices  to  show  <p{uc )  v'. 

This  is  trivial,  since  uc  =  [rt']  and  v'c  =  \y"\ 

Case  SOFT-ASSIGN  (((soft  ms).xc  ■■=  v,Mi)  —>  {e[  *-a  (anp),M[),  where 

(ms.xc  :=  v,  Mi)  4  (e'i,  M[)  and  S  =  {xi :  rj(a,p)): 

We  proceed  by  cases  according  to  the  evaluation  rules  for  ( ms.xc  :=  v ,  Mx )  — 

(el,  M(). 

Sub-case  ASSIGN  (( ms.xc  :=  v,M±)  M  (*  ►Q,p,  Mi['ms.xc  v  >a  rc])): 

_ v 

Let  and  u,  be  such  that  M[(ms)  =  {:r,  =  c'}  and  M2((j)(ms))  = 
{xi  -  u)}.  We  therefore  have  v'c  =  v  >arc. 

From  0;pc;7f  t-  (soft  ms).xc  :=  v  :  r,  X,  we  know  h  t'  n  pc  <  rc,  for 
some  r'.  We  therefore  know  h  integ(rc)  pc.  So,  from  a  £  pc,  we  have 
a  j:  integ(rc).  Therefore,  v'c  is  a  bracketed  value:  there  exists  a  v"  such 
that  v'c  =  [<]. 

From  M2  and  cc  ^  integ(rc),  we  also  know  uc  is  a  bracketed  value: 
uc  =  [u'c],  for  some  u'c. 
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1.  Suppose  4>{M\)  M2.  We  show  4>(M[)  »a  M2. 

Assume  ms  e  dom(0)  (otherwise,  the  result  follows  directly  from 
!«a  M2).  Since  0(Mi)  M2>  it  suffices  to  show  (p(v'c )  rjq,  mc. 

This  is  trivial,  since  v'c  =  [v")  and  uc  =  \u'c]. 

2.  Suppose  (ei,  Ah)  and  </>(M2)  M(.  We  show  (f>(M2)  ~Q 

Assume  ms  €  im(0)  (otherwise,  the  result  follows  directly  from 
4>{M2)  «a  Mi).  Since  c f>(M2 )  «Q  Mi,  it  suffices  to  show  4>(uc)  v'c. 
This  is  trivial,  since  uc  =  [//(]  and  v'  =  \v"~\. 

Sub-case  DANGLE-ASSIGN  (( ms.xc  :=  v,Mi )  —>  (ip  >ap,  Mi)): 

The  result  holds  trivially,  since  M[  =  Mi. 

Case  EVAL-CONTEXT  {{E\e3\,  Mx)  —>  (E\e3],  M[),  where  ( e3,Mi )  —>  { e3,M[ )): 

A  case  analysis  on  the  syntax  of  E\  ■  ]  shows  that  from  the  derivation  of 
0;pc;7f  h  E[e3]  :  r,  A,  we  know  0-,pc;'hr  h  e3  :  r',A',  for  some  H' ,  r' , 
and  X' .  Therefore,  we  can  apply  the  induction  hypothesis  and  obtain  the 
result. 

Case  Bracket-Context  (([e3], Mi)  A-  ([e3\,M[),w here  (e3, Mi)  4  (e3,M[)): 

From  the  derivation  of  0;pc;7f  t-  [e3]  :  r,  A,  we  know  0;  pc  n  i\  H  e3  : 
r' ,  A,  where  a  ^  £  and  r  =  t'  n  i.  Therefore,  we  can  apply  the  induction 
hypothesis  and  obtain  the  result. 


□ 
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We  can  now  state  our  referential  security  theorem,  which  encompasses  both 
referential  integrity  and,  via  Lemma  20,  immunity  to  storage  attacks. 

Theorem  1  (Referential  security).  Let  (e, ,  A/, )  be  a  well-formed  configuration 
wherein  e\  has  type  r.  Let  e2  be  an  expression  also  of  type  r,  and  let  M2  be  well-formed, 
such  that  (e2,M2)  is  a  well-formed  non-adversarial  configuration.  Let  f  be  a  high- 
integrity  homomorphism  from  Mi  to  M2  such  that  (ei,Mi)  is  equivalent  to  (e2,M2) 
via  0.  Suppose  (ei,Mi)  takes  some  number  of  steps  in  the  presence  of  an  adversary  to 
another  configuration  {e\ ,  M[). 

{ex,  Mf)  a  0;  pc\  Li  v-  ei  :  r,  X 
a  t-[u,f]  (e2,  M2)  a  0;  pc\  U  v-  e2  :  r,  T a  M2 

a  0(ei,  Mi)  «iQ  (e2,  M2)  a  {ei,Mf)  -+*Q  {e[,M[) 

Then  either  (e2,  M2)  diverges,  or  it  can  take  some  number  of  steps  in  the  absence  of  an 
adversary  to  another  configuration 

3 <e2,M2>^ 

and  there  exists  a  high-integrity  homomorphism  ft  from  M[  to  M'2  that  extends  f,  such 
that  (e[,M[)  is  equivalent  to  (ef  Mf)  via  ft: 

ft(e'ii  M[)  (e'2,M') 

Proof  If  we  can  show  this  is  true  for  the  case  where  a  single  -+a  step  is  taken 
to  reach  {e\ ,  M[),  then  the  rest  follows  by  induction  on  the  number  of  ->a  steps 
taken.  (We  know  the  induction  hypothesis  will  apply  because  of  Corollary  11 
and  the  fact  that  \-[wf]  (e2,  M2)  a  if]  M2  (e2,  M2).) 

We  show  the  single-step  case  by  induction  on  the  derivation  of  (ei,  Mf) 
(e[,M[).  Assume  that  (e2,M2)  does  not  diverge.  The  proof  proceeds  by  cases 
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according  to  the  evaluation  rules.  For  each  case,  we  need  to  show  two  things 
about  e'2,  M2,  and  0': 

i.  Expression  equivalence:  0'(e' )  e2  and 

ii.  Memory  equivalence:  4>'(M[)  ~Q  M2. 

It  will  be  obvious  by  its  construction  that  0'  is  a  high-integrity  homomorphism 
that  extends  0. 

Case  CREATE  ({{xi  =  v'i}s,  Ml)  -*-a  (mf,Mi[mf  {Xi  -  Vi  r]}]),  where  m\  is 
fresh  and  S  =  {x^ : 

From  0(ei)  e2,  we  know  e2  =  {xi  =  u'i}s  with  0(v0  »a  ut  for  all  i.  By 

Create, 

(e2,M2)  ->  (mf,M2[mf  >-»  =  tt*  ►aTi}]) , 

where  m2  is  fresh.  Choose  0'  =  0[mf  ^  mf]. 

i.  We  need  to  show  0'(mf )  mf . 

This  follows  by  construction  of  0'. 

ii.  We  need  to  show  0'(M{)  M!2,  where  =  Mi[mf  { x,  =  vt  >a  t,)] 

and  M2  =  M2[m2  =  Ui  ►Q  r,}]. 

First,  let  ms'  e  dom(0')  be  such  that  ±  1.  We  show  that 

M2(cj)' (ms' ))  ±  1  and  cj)'(M[(ms'))  M2((ft'(ms')). 

If  m5,  =  mf,  then  M[(ms ')  =  =  {xi  -  Vi  >a  t]}  and 

M2{4>'{ms'))  =  M2(m2)  =  {a;;  =  w*  ►,*  t,},  so  the  result  follows  from  the 
assumption  0(ei)  e2  via  Lemmas  29  and  30.  Otherwise,  m5'  ^  mf, 
so  and  M2(4>'(ms’))  =  M2(0(m5,)).  The  result 

therefore  follows  from  the  assumption  0(Mi )  M2. 
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Now,  let  ms'  e  dom(0')  be  such  that  \-  a  4  auth+(5,/)  n  persist^')  and 
-  1.  We  show  that  M'2{<f)' (ms> ))  =  1.  Since  =  l, 

we  must  have  ms'  +  mf,  so  M[(ms')  -  M i  (rns' )  and  M^cj)' (ms‘ ))  = 
M2(</>(ms')).  The  result  therefore  follows  from  the  assumption 

0(MX)  *Q  M2. 

Case  SELECT  ((mf.xc,Mi)  -+a  (vc*-ap,Mi),  where  S  =  {xi :  Ti}(a,P )  and 
Mi(mf)  =  {xi  =  v)}): 

From  4>(ei)  na  e2,  we  know  e2  =  mf  .xc,  where  0(mf )  =  mf .  Therefore,  from 
4>{M\)  Ria  M2,  we  have  M2(mf)  =  {a:*  =  w,;}  for  some  u),  where  4>(vi)  rjq 
So,  by  SELECT,  (e2,  M2)  -»•  ( uc  >a  p,  M2).  Choose  0'  =  0. 

i.  We  need  to  show  <p(vc  >a  p)  uc  >a  p. 

This  follows  via  Lemma  29. 

ii.  We  need  to  show  0(Mi)  M2. 

This  is  given. 

Case  DANGLE-SELECT  ((mf.xc,Mi)  -> a  (ip  *-ap,  Mi),  where  S  =  {xi  ■  Ti}(a,P) 
and  Mi(mf )  =  l): 

From  b-“^  (mf.xc,Mi),  nc(mf,(mf.xc,Mi)),  and  Mi(mf)  =  1,  we  know 
a  ^  p.  Therefore,  Lp  ►„  p  =  [lp].  From  0(ei)  ~Q  e2,  we  know  e2  =  mf.xc. 

If  M2(mf )  =  1,  then  by  DANGLE-SELECT,  (e2,  M2)  -*  ([ip],  M2). 

Otherwise,  without  loss  of  generality,  assume  M2(mf)  =  {a:,  =  «f}.  Since 
a  ^  p,  we  have  uc  *-ap  =  [u']  for  some  So,  by  SELECT,  (e2,M2)  -> 
([<],M2). 

Choose  0'  =  0. 
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i.  We  need  to  show  that  0([_LP])  *a  [u]  for  u  e  {u'c,  _LP}. 

This  is  trivial. 

ii.  We  need  to  show  that  »a  M2. 

This  is  given. 

Case  Soft-Select  (((soft  mf).xc,Mi)  -+a  {v',Mi),  where  ( mf.xc,Mi )  —> 
(v,  Mi),  S  =  {xi :  Ti}(a,p)),  and  v'  =  v  >a  (anp): 

From  (f)(e i)  e2,  we  know  e2  =  ((soft  mf).xc),  where  4>(mf)  =  mf.  If  we 
can  find  u  so  that  (mf.xc,  M2)  A-  (u,M2),  then  by  SOFT-SELECT,  we  have 
(e2,M2)  =  ((soft  mf).xc, M2)  -»•  (tt  (anp), M2).  Choose  4>'  =  <fi. 

We  proceed  by  cases  according  to  the  evaluation  rules  for  (mf.xc,Mi)  A- 

Sub-case  SELECT  (y  =  vc  >ap,  where  Mi(mf )  =  =  y)}): 

From  (p ( A'I\ )  M2/  we  know  M2(mf )  =  =  uf}  for  some  ft),  where 
0(vj)  RiQ  Ui.  So,  by  SELECT,  we  have  (mf.xc,M2)  A-  (uc>ap,  M2). 
Therefore,  u  =  uc>-ap. 

i.  We  need  to  show  0((uc  ►ap)  ►a  (anp))  rjq  (uc  >ap)  ►«  (anp). 
This  follows  via  Lemma  29. 

ii.  We  need  to  show  4>{Mi)  ~,y  M2. 

This  is  given. 

Sub-case  DANGLE-SELECT  (v  =  Lp  ►ap,  where  Mi(mf)  =  l): 

First,  suppose  i-  a  =»  a  n  p.  Then  v  (anp)  =  _Lp,  (anp)  =  w,  and 
ha^p.  Therefore,  we  have  mf  e  dom(0),  and  so,  <j)(mf )  =  mf.  From 
d(Mi)  »a  M2,  then,  we  know  M2(mf )  =  1.  So,  by  SELECT,  we  have 
(mf.xc,  M2)  A-  (l p,M2).  Therefore,  u  =  lp. 
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i.  We  need  to  show  <f>(lp)  Lp. 

This  is  trivial. 

ii.  We  need  to  show  <i>(M\ )  &a  M2. 

This  is  given. 

Now,  suppose  a  $  an  p.  Then  v  >a  (an  p)  =  [ip],  If  M2(mf)  =  1, 
then  by  DANGLE-SELECT,  (mf.xc,  M2)  {lp  *-ap,M2).  Otherwise, 
without  loss  of  generality,  assume  M2(mf )  =  {a;*  =  uj.  So,  by  SELECT, 
(mf.a;c, M2)  A-  (mc  >ap,M2).  Therefore,  u  ►a  (anp)  e  {(ip  >ap)  (an 
p) ,  (uc  ►a  p)  ►«  (a  n  p) }  =  { [ip] ,  [u’c] },  for  some  u'c. 

i.  We  need  to  show  0([ip])  [«/]  for  w/  e  {a',  lp}. 

This  is  trivial. 

ii.  We  need  to  show  <i>(M\ )  M2. 

This  is  given. 

Case  ASSIGN  ((mf.xc:=v,Mi)  -*Q  {*  >ap,  Mi[mf.xc  v  >a  tc]),  where 

Mi(mf)  *  1  and  S  =  {i“T 7^}(a,p)): 

From  0(ei)  rjq  e2,  we  know  e2  =  (mf.ay  :=  w)  with  0(mf)  =  mf  and 
0(c)  rsq  u.  From  0(Mi)  «Q  M2,  we  have  M2(mf)  *  1.  So,  by  ASSIGN, 
(m^.Xc  :=  rt,  M2)  -»•  (*  ►q,  p,  M2[mf  .xc  u  >q  rc]).  Choose  0'  =  0. 

i.  We  need  to  show  0(*  ►a  p)  *  >a  p. 

This  follows  via  Lemma  29. 

ii.  We  need  to  show  0(Mi[mf  .xc  ^  v  >a  rc])  M2[mf  .xc  ^u>a  rc]. 

First,  let  mg0  e  dom(0)  be  such  that  M[ (mf° )  *  l.  We  show  that 
M^((p(rnQ0))  1 1  and  0(M((mf °))  ~Q  M^^rn^0)). 

If  Wq0  =  mf,  then  0(mf°)  =  mf.  Let  '  and  ui'  be  such  that  M((mf )  = 

_ i  _ v 

{xj  =  c'}  and  M 2(70*2 )  =  {xi  =  a'}.  Since  0(f)  u,  by  Lemma  29,  we 
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have  4>{v  >a  rc )  &a  u  ►„  rc.  Since  v'c  =  v  *a  tc  and  u'c  -  u  >a  rc,  we 
therefore  have  (f)(v'c)  rjq  u'c.  Therefore,  from  o(M\ )  &a  M2,  it  follows 

_ v  _ i 

that  (p({xi  =  v-})  {xi  =  u,i}. 

Otherwise,  mf°  +  mf,  so  M[ (m,f° )  =  Mi(mjf°)  and  M^c/^mf0))  = 
M2(0(m o°))-  The  result  therefore  follows  from  o{M\ )  ~Q  M2. 

Now,  let  mf°  e  dom(0)  be  such  that  b-  a  3  auth+(S0)  n  persist(S'o)  and 
M[ (m(j° )  =  i.  We  show  that  AF)(©(mf°))  =  1.  This  follows  from 
0(Mi)  «a  M2  by  construction  of  and 

Case  DANGLE-ASSIGN  ((mf.xc-=v,Mi)  ->Q  (ip>ap,Mi)r  where  S'  = 
{A  :  A}(a,P)  and  Mi(m5)  =  l): 

From  (mf.xc  :=  v,  M\),  nc(mf ,  (mf  .ay,  :=  v,  Mi)),  and  Mi(mf )  =  1,  we 

know  a  ^  p.  Therefore,  Ip  ►«P=  [ip]- 

From  4>(ei)  ~Q  e2,  we  know  e2  =  mf  .ay  :=  u  with  0(mf )  =  mf  and  0(v)  u. 
If  M2(mf )  =  1,  then  by  DANGLE-ASSIGN,  (e2,  M2)  ->  ([ip],  M2). 

Otherwise,  M2(mf)  *  1.  Since  a  ^  p,  we  have  *  >ap  -  [*].  So,  by  ASSIGN, 
(e2,M2)  ->  ([*],M2[m$.xc»u  ►aTc]). 

Choose  4>'  =  cj). 

i.  We  need  to  show  d([lP])  ~Q  [«']  for  -u'  e  {*,  ip}. 

This  is  trivial. 

ii.  We  need  to  show  4>(M[)  ~(;i  M!2. 

First,  let  m f°  e  dom(0)  be  such  that  M[(mf0)  +  1.  We  show  that 
M^^mf0))  *  1  and  d(M[(mf0))  »a  M^^mf0)). 

Since  M[  =  AT,  and  M[  ( mf° )  *  i,  we  must  have  m0s"  *  mf,  so 
=  M i  (mf° )  and  M^^mf0))  =  M2(0(mf0)).  The  result  there¬ 
fore  follows  from  0(Mi)  ~Q  M2. 
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Now,  let  mf°  €  dom(0)  be  such  that  h  a  3  auth+(5'0)  n  persist(S'o)  and 
M[ (mf° )  =  i.  We  show  that  AF((©(mf0))  =  1.  This  follows  from 
)  «Q  M2  by  construction  of  M2. 

Case  SOFT-ASSIGN  (((soft  mf).xc  :=  v,M])  -+a  (t/  >9  (a  n p),M[),  where 

(mf.xc  :=  v,  Mi)  4  (r/,  M()  and  S'  =  {x*  :  rj(a,p)): 

From  0(ei)  ~a  e2,  we  know  e2  =  ((soft  rn2).xc  :=  w)  with  0(mf)  = 
mf  and  0(x)  rsq  u.  If  we  can  find  a  configuration  (u',M2)  so  that 
(m2.xc  :=  M2)  (u',M'2),  then  by  SOFT- ASSIGN,  we  have  (e2,M2)  = 

((soft  m2).xc  ■■=  u,M2)  ->  (i//  ►a  (a  np),M2).  Choose  <f>'  =  0. 

We  proceed  by  cases  according  to  the  evaluation  rules  for  (mf.xc  :=  v,  M { )  - 


Sub-case  ASSIGN  (r/  =  *  p  and  M[  =  Mi[/7rf.xc  h*  v  >a  rc],  where 

1 1): 

From  0(M, )  M2,  we  know  M2(mf )  *  1.  So,  by  ASSIGN,  we  have 

(m2.xc  :=  u,M2)  (*  ►aP,  M2 [mf.xc  >-»  u  ►a  rc]) . 

So  u'  =  *  *ap  and  M2  =  M2[m2.xc  u  >a  rc]. 

i.  We  need  to  show  0((*  ►ap)  (anp))  (*  p)  (anp). 

This  follows  via  Lemma  29. 

ii.  We  need  to  show  0(1^  [mf  .xc  h*-  v  ►Q  rc])  M2[mf.xc  h*  u  ►q  rc]. 
First,  let  mf°  €  dom(0)  be  such  that  M[ (m0s'° )  *  1.  We  show  that 
M2((f>(mQ0))  1 1  and  0(M[(mf0))  »a  M2(cj)(mQ0)). 

If  wig  =  mf,  then  0(mf°)  =  mf.  Let  70  and  70'  be  such  that 

_ i  _ v 

M((mf)  =  {x,  =  u'}  and  M2(m2)  =  {xi  -  u[}.  Since  0(v)  u, 
by  Lemma  29,  we  have  (f>(v  ►a  rc)  u  *a  tc.  Since  =  v  >a  tc 
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and  u'c  =  u  >a  tc,  we  therefore  have  4>(v'c)  u'c.  Therefore,  from 

_ v  _ i 

(p{M\ )  »a  M2/  it  follows  that  4>({xi  =  v[})  ~Q  {xi  =  u[}.  Otherwise, 
mQ0  +  mf,  so  M[ (m(j'° )  =  M i  (rn^° )  and  M2(cj)(mQ0))  =  M2(0(777q°)). 
The  result  therefore  follows  from  4>(Mi)  &a  M2. 

Now,  let  777 q°  e  dom(0)  be  such  that  b-  a  ^  auth+(5o)  n  persist(S'o) 
and  M[(m q°)  =  1.  We  show  that  M2(d>(rn^0))  =  1.  This  follows 
from  4>(Mi)  ~0:  M2  by  construction  of  M{  and  M2. 

Sub-case  DANGLE-ASSIGN  (7/  =  _LP  >ap  and  =  Mi,  where  M1(777f )  =  l): 
First,  suppose  h  a  3  anp.  Then  v'*a(anp)  =  ip  and  u' >a(anp)  =  u’ ,  and 
from  0(Mi)  M2,  we  know  M2(m2 )  =  1.  So,  by  DANGLE-ASSIGN, 

we  have  ( m2.xc  :=  77,  M2)  A-  (lp  ►„ p, M2).  Therefore,  u'  =  _LP  p  -  _LP 
and  M2  =  M2. 

i.  We  need  to  show  0(ip)  ip. 

This  is  trivial. 

ii.  We  need  to  show  4>(Mi)  &a  M2. 

This  is  given. 

Now,  suppose  anp.  Then  v'  *-a  (anp)  =  [ip]. 

If  M2(m2)  =  1,  then  by  DANGLE-ASSIGN,  (m2.xc:=  u,  M-2)  —> 
(l p>aP,M2).  Otherwise,  M2(m2 )  ±  1,  and  by  ASSIGN, 

(m2.xc  u,M2)  A-  (*  ►a p,  M2[mf  ,xc  77  >a  rc]).  Therefore,  u'  >a  (a  n 
p)  e  {(w  *-ap)  ►<*  (anp),  (*  ►ap)  (anp)}  =  {[lp],[*]}. 

i.  We  need  to  show  0([lp])  rjq  [ u ']  for  77'  e  {*,  _Lp}. 

This  is  trivial. 

ii.  We  need  to  show  < f)(M[ )  ~,y  M2. 

First,  let  777 q°  €  dom(0)  be  such  that  M( (rn^° )  *  1.  We  show  that 
M2(cj)(mQ0))  +  1  and  0(M{(tt7q °))  »a  M2((j)(rriQ0)). 
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Since  M[  =  Mx  and  M[ (m0s'° )  *  1,  we  must  have  mj-°  £  mf,  so 
M[ (mf° )  =  Mi(mf°)  and  M^irn^0))  =  M2(0(mf0)).  The  result 
therefore  follows  from  0(Mi)  M2. 

Now,  let  mf°  e  dom(0)  be  such  that  i-  a  =>  persist(S'o)  and 
M[(mf0)  -  1.  We  show  that  M '^0(111^'))  =  1.  This  follows  from 
0(M,)  M2  by  construction  of  Mf. 

Case  Apply  (((A(a;:T)|j?c;Tf].  e3)  vi,Mx)  (e3{ri/x},Mi)): 

From  0(e4)  e2,  we  know  that  e2  =  ((A(a;  :  r)[pc;  “H].  e4)  v2), 

where  0(e3)  rjq  e4  and  <p(vi)  v2.  By  APPLY,  we  have 

((A(x:t )[pc;  'H\.  e4)  v2,M2)  ->  (e4{v2/a;},  M2).  Choose  0'  =  0. 

i.  We  need  to  show  0(e3{vi/a;})  Ria  e4{v2/a;}. 

This  follows  by  Lemma  28. 

ii.  We  need  to  show  0(M4)  M2. 

This  is  given. 

Case  EXISTS-TRUE  ((exists  soft  mf  as  x  :  e3  else  e4,  AT, )  ->a 

((e3{mf/x})  ►«  (a  np),M1),  where  M1(mf)  ±  1  and  S'  =  {T7Th}(a,P)): 

From  0(e4)  e2,  we  know  that  e2  =  exists  soft  mf  as  x  :  e5  else  e6,  where 

0(mf)  =  mf  and  0(e3)  Ria  e5.  Since  0(M|)  »a  M2  and  M4(mf)  ^  1,  we 
know  M2(mf )  ^  1,  so  by  EXISTS-TRUE,  we  have 

(exists  soft  mf  as  a: :  es  else  e§ ,M2)  -*■  ((es{mf/x})  ►a  (a  n p),M2) 

Choose  0'  =  0. 

i.  We  need  to  show  0((e3{mf/x})  (a  np))  (e5{mf/x})  ►a  (anp). 

This  follows  by  Lemmas  28  and  29. 
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ii.  We  need  to  show  0(M; L)  rjq  M2. 

This  is  given. 

Case  ExiSTS-FALSE  ((exists  soft  mf  as  x  ■  e3  else  e4,  Mi)  ->a  (e4  (anp),Mi), 
where  S  =  (a,P)  and  Mi(mf)  =  l): 

From  0(ei)  e2,  we  know  that  e2  =  exists  soft  mf  as  a;  :  e5  else  e6/  where 

0(mf )  =  mf  and  0(e4)  »a  e6.  We  proceed  by  cases  according  to  whether 

i-  a  4  a  n  p. 

Sub-case  a  4  an p: 

We  therefore  know  e4  ►„  (anp)  =  e4  and  a  4  p.  So,  from  M2 

and  Mi(mf )  =  1,  we  know  M2(mf )  =  1,  so  by  EXISTS-FALSE,  we  have 
(exists  soft  mf  as  a: :  e5  else  e6,  M2)  ->  (e6,  M2).  Choose  <f>r  =  4>. 

i.  We  need  to  show  0(e4)  e6. 

This  is  given. 

ii.  We  need  to  show  M2. 

This  is  given. 

Sub-case  anp: 

We  therefore  have  e4  (anp)  =  [e^]  for  some  e'4.  If  M2(mf)  =  1, 
then  by  EXISTS-FALSE,  we  have  (exists  soft  mf  as  a; :  e5  else  e6,  M2)  -»• 
([eg],M2),  for  some  e'6.  Otherwise,  by  EXISTS-TRUE,  we  have 
(exists  soft  mf  as  x  :  e5  else  e6,M2)  ->  ([e^Mj),  for  some  e(.  Choose 

0'  =  0- 

i.  We  need  to  show  ^([e^])  [ef]  for  ef  e  {e'5,  e'6}. 

This  is  trivial. 

ii.  We  need  to  show  <p(Mi )  M2. 

This  is  given. 
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Case  TRY-VAL  ((try  v4  catch  p:  e3,  Mi)  ->a  (vi,Mi),  where  'ip'.  V\  +  ip  and 
di  #  [v(]): 

From  0(ei)  «a  e2/  we  know  that  e2  =  (try  v2  catch  p:  eft,  where  <j>(v i)  «n 
v2  and  0(e3)  «a  64.  From  this,  it  follows  that  by  TRY-VAL,  we  have 
(try  v2  catch  p:  e4,  M2)  -»•  (v2,  M2).  Choose  ft  =  ft 

i.  We  need  to  show  (f>(vft  ~Q  v2. 

This  is  given. 

ii.  We  need  to  show  (j>(Mi)  na  M2. 

This  is  given. 

Case  TRY-CATCH  ((try  ip  catch  p:  e3,Mi)  -*-a  (e3,  Mft,  where  e-  p  4  p')\ 

From  4>{e  1)  e2,  we  know  that  e2  =  (try  ip  catch  p:  e4),  where  0(e3)  Ria  e4. 
By  TRY-CATCH,  we  have  (try  lp  catch  p:  e4,  M2)  -*■  (e4,  M2).  Choose  ft  =  (j). 

i.  We  need  to  show  0(e3)  e4. 

This  is  given. 

ii.  We  need  to  show  <b{M\ )  » ia  M2. 

This  is  given. 

Case  TRY-ESC  ((try  1  p  catch  p:  e3,  Mi)  -+a  {lp,  Mi),  where  p  $  p')\ 

From  4>{eft  ~a  e2,  we  know  that  e2  =  (try  lp  catch  p:  e4).  By  TRY-ESC,  we 
have  (try  lp  catch  p:  e4,  M2)  -»•  (1^,  M2).  Choose  ft  =  ft 

i.  We  need  to  show  <f>(lp)  V- 
This  is  trivial. 

ii.  We  need  to  show  ftAdft  M2. 

This  is  given. 
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Case  Parallel-Result  ((viiiv2,Mi)  {*,Mft): 

From  </>(ei)  e2/  we  know  that  e2  =  u \  i m2,  where  Ui  for  i  €  {1,2}. 

By  Parallel-Result,  we  have  (wiiiw2,M2)  -» (*,M2).  Choose  ft  =  0. 

i.  We  need  to  show  </>(*)  *. 

This  is  trivial. 

ii.  We  need  to  show  (p(Aft)  &a  M2. 

This  is  given. 

Case  IF-TRUE  ((if  true  then  e3  else  e4,  Aft)  -»-a  (e3,  Mi)): 

From  c/>(ei)  e2,  we  know  that  e2  =  (if  true  then  e5  else  eft,  where  </>(e3) 

e5.  By  IF-TRUE,  we  have  (if  true  then  e5  else  e6,  M2)  -»•  (e5,M2).  Choose 

ft  =  ft 


i.  We  need  to  show  0(e3)  e5. 

This  is  given. 

ii.  We  need  to  show  (p(Aft)  ~Q  M2. 

This  is  given. 

Case  IF-FALSE  ((if  false  then  e3  else  e4,Aft)  ->a  (e4,Mft): 

From  (j)(eft  na  e2,  we  know  that  e2  =  (if  false  then  e5  else  eft,  where  fteft  « a 
e6.  By  IF-FALSE,  we  have  (if  false  then  e5  else  e6,  Aft)  -*■  (e6,Aft).  Choose 

ft  =  ft 


i.  We  need  to  show  <j>(e4)  e6. 

This  is  given. 

ii.  We  need  to  show  (p(A/ft )  M2. 

This  is  given. 
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Case  Let  ((let  x  =  Vi  in  e3,Mi)  {e3{vi/x},  M3),  where  Vp.  vx  +  ip  and 
Vv[.  vi  +  [v(]): 

From  4>{e i)  «Q  e2/  we  know  that  e2  =  (let  x  =  c2  in  e4),  where  0(c4)  u2  and 
0(e3)  «a  e4.  By  LET,  we  have  (let  x  =  v2  in  e4,  M2)  -»•  (e4{i>2/x},  M2).  Choose 
<P'  =  (j>. 

i.  We  need  to  show  <p(e3{vi/x})  e4{v2/a;}. 

This  follows  by  Lemma  28. 

ii.  We  need  to  show  M2. 

This  is  given. 

Case  EVAL-CONTEXT  ((E[e3\,  Mi)  -+a  (E[e3],M[),  where  (e3,Mi)  A-  (e'3,M[)): 

We  proceed  by  cases  according  to  the  syntax  of  E[  ■  ].  We  only  show  the 
case  £[  •  ]  =  try  [  •  ]  catch  p:  e4;  the  other  cases  follow  similarly. 

Sub-case  E[-]~  (try  [ •  ]  catch  p:  e4): 

From  0(e4)  «a  e2,  we  know  e2  =  (try  e5  catch  p:  e6),  where  0(e3)  e5 
and  0(e4)  xa  e6.  To  apply  the  induction  hypothesis,  we  need: 

•  h[wf]  (e3,Mi)  and  ^[wf\  (e5,M2) 

These  follow  from 


(try  e3  catch  p:  e4,  Mi) 

and 

I- [ay]  (try  e5  catch  p:  e6,  M2) . 

•  0;  pc;  W  t-  e3  :  r',  TC  and  0;  pc;  H’  v-  e5  :  r',  TC,  for  some  r',  dC 
These  follow  from  the  typing  derivations  for  try  e3  catch  p:  e4  and 
try  es  catch  p:  e6- 
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#  ^[wf]  ^2  and  0(^3,  Ml)  ~Q  (es,  M2). 

These  are  given. 

Therefore,  we  can  apply  the  induction  hypothesis  to  get  a  configura¬ 
tion  (e^,  M^)  and  a  high-integrity  homomorphism  ft  from  M[  to  M!2 
that  extends  4>,  such  that  (e5,  M2)  -»•  (e’5,  M2)  and 

0'<e',Mi'K(e',M').  (3.14) 

So,  by  EVAL-CONTEXT,  we  have 

(try  e5  catch  p:  e^,  M2)  -»•  (try  eg  catch  p:  e&,  M2) . 

From  (3.14),  we  know  0'(try  e(j  catch  p:  e4,  M{)  (try  eg  catch  p:  e6,  M^), 
as  desired. 

In  case  E[  ■  ]  -  soft  [  •  ],  where  e2  =  soft  e4,  to  apply  the  induction  hypoth¬ 
esis,  we  need  the  additional  fact  that  since  e3  is  not  a  value,  neither  is  e4, 
and  therefore  (soft  e3,  M4)  and  \-[wf]  (softe4,M2)  imply  i-“y/]  (e3,M4) 
and  (e4,M2). 

Case  Fail-Prop  ((F[ip],Mi)  (_lp,Mi)): 

From  0(e4)  rJq,  e2,  we  know  that  e2  =  F'[ _Lp],  By  FAIL-PROP,  we  have 
(F'[ip],M2)  ->  (1  p,M2).  Choose  ft  =  ft 

i.  We  need  to  show  0(_Lp)  ip. 

This  is  trivial. 

ii.  We  need  to  show  0(M4)  M2. 

This  is  given. 
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Case  GC  ((ei,Mi)  -+a  (ei ,  Mi[G  ^  i]),  where  gc(G,  (ei,Mi))): 

By  Lemma  27,  let  G'  be  such  that  C  £  G'  £  0(G)  and  gc(G',  (e2,  M2)),  where 

C  =  {(j)(rns)  :  m5  eGn  dom(0)A  i-  u  ^  auth+(5')  n  persist(S')} 

and 

0(G)  =  {0(ms)  :  m5  €  G  n  dom(0)}. 

Then,  by  GC,  we  have  (e2,  M2)  -»•  (e2,  M2[G'  j.]).  Choose  0'  =  0. 

i.  We  need  to  show  0(ei)  e2. 

This  is  given. 

ii.  We  need  to  show  0(Mi[G  h*  i])  M2[G'  i]. 

First,  let  mf0  e  dom(0)  be  such  that  M((mf°)  +  1.  We  show  that 
M^(d(rn^0))  +  l  and  0(A/}(mf0))  »a 

Since  M[ (mf0 )  #  1,  we  know  nig0  f  G  and  0(mf°)  /  G'.  Therefore, 
M[(-mf0)  =  M^mf0)  and  M^im^0))  =  A-/2(0(mf0)),  so  the  result  fol¬ 
lows  from  the  assumption  4>(Mi)  &a  A-/2. 

Now,  let  mf°  e  dom(0)  be  such  that  i-  a  =>  auth+(S,0)  n  persist(S'o) 
and  M[(mf0)  =  1.  We  show  that  A/^(0(mf0))  =  l.  If  -mf°  e  G,  then 
0(mo°)  e  G',  and  the  result  follows  by  construction  of  A/0  Otherwise, 
■mf°  ^  G,  and  so,  0(mf°)  ^  G'.  Therefore,  M{(mf°)  =  Mi(m f°)  and 
A/2(0(mg0))  =  M2(0(mf0)),  so  the  result  follows  from  the  assumption 
0(Mr)  ~q  AT2. 

Cases  Bracket-Select  and  Bracket-Soft-Select 

(([u].xc,  Mi)  ([v.xc\,  Mi),  where  v  e  (mf1,  soft  mf1}): 

From  0(ei)  Ria  e2,  we  know  that  e2  =  [«].&<..  From  the  grammar,  we 
must  have  u  £  {mf2, soft  mf2}.  If  u  =  mf2,  then  by  BRACKET-SELECT, 
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([mf 2\xci  M2)  -*■  ([mf2.xc],  M2).  Otherwise,  u  =  soft  m22,  and  by  BRACKET- 
Soft-Select,  ([soft  rri22].xc,  M2)  -»•  ([(soft  mf2).xc],  M2).  Choose  0'  =  0. 

i.  We  need  to  show  0([v.xc])  rsq  [ u.xc ]. 

This  is  trivial. 

ii.  We  need  to  show  0(Mi)  M2. 

This  is  given. 

Case  Bracket- Assign  ({[v1].xc:=v2,M1)  -+q  ([ui.xc  :=u2],Mi)): 

From  0(ei)  e2,  we  know  that  e2  =  [rti].xc  :=  u2.  By  BRACKET- ASSIGN, 

we  have  ([ui].xc  :=  rt2,M2)  -»•  ([«i.a;c  :=  w2],  M2).  Choose  0'  =  0. 

i.  We  need  to  show  0([vi.xc  :=  u2])  »a  [«i.a;c  :=  w2]. 

This  is  trivial. 

ii.  We  need  to  show  0(Mi)  M2. 

This  is  given. 

Case  Bracket-Soft  ((soft  [v],Mi)  -*a  ([soft  v],  Mi)): 

From  0(ei)  e2,  we  know  that  e2  =  soft  [e3].  Since  (e2,M2)  is  assumed 

to  not  diverge,  (e3,M2)  cannot  diverge  either.  So,  by  Corollary  14,  there 
is  a  configuration  (u,M'2)  such  that  (e3,M2)  —>■*  (u,M2).  Then  by  EVAL- 
Context,  Bracket-Context,  and  Bracket-Soft,  we  have 

(soft  [e3],  M2)  (soft  [u],M'2)  ->  ([soft  u],M'2) . 

Choose  0'  =  0. 

i.  We  need  to  show  0([soft  v])  &a  [soft  u\. 

This  is  trivial. 
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ii.  We  need  to  show  )  » iq  M'2. 

This  follows  by  Lemma  31. 

Case  Bracket-Exists 

((exists  [v]  as  x  :  e3  else  e4,  Mi)  ([exists  v  as  x  :  e3  else  e4],  M4)): 

From  0(e i)  e2,  we  know  that  e2  =  exists  \u\  as  x  :  e5  else  eg.  By  BRACKET- 
EXISTS,  we  have 

(exists  [u]  as  a: :  e5  else  e6,  M2)  ->  ([exists  wasi:  e5  else  e6],  M2) 

Choose  q b'  =  0. 

i.  We  need  to  show  0( [exists  v  as  a: :  e3  else  e4])  [exists  u  as  x  ■  e5  else  e6]. 
This  is  trivial. 

ii.  We  need  to  show  0(M4)  *>a  M2. 

This  is  given. 

Case  Bracket- Apply  (([v4]  v2,M1)  -+a  ([v4  v2 

From  0(e4)  e2/  we  know  that  e2  =  ([«i]  u2).  By  BRACKET- APPLY,  we 

have  {[ui]  u2,M2)  -»•  ([to  m2],M2).  Choose  ft  =  0. 

i.  We  need  to  show  <p([vi  v2 ])  ~a  [u4  rt2]. 

This  is  trivial. 

ii.  We  need  to  show  0(M4)  M2. 

This  is  given. 
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Case  BRACKET-TRY  ((try  [v]  catch  p:  e3,  Mi)  -+a  ([try  v  catch  p:  e3],  Mi)): 

From  0(ei)  «Q  e2,  we  know  that  e2  =  (try  [e4]  catch  p:  e5).  Since  (e2,M2) 
is  assumed  to  not  diverge,  (e4,M2)  cannot  diverge  either.  So,  by  Corol¬ 
lary  14,  there  is  a  configuration  (rt,  Ml,)  such  that  (e4,  M2)  ( u ,  M^).  Then 
by  Eval-Context,  Bracket-Context,  and  Bracket-Try,  we  have 

(try  [e4]  catch  p:  e5,M2)  -»■*  (try  [u]  catch  p:  e5,  M'2)  -»•  ([try  u  catch  p:  e5],M2) . 

Choose  ()'  =  4>. 

i.  We  need  to  show  0([try  v  catch  p:  e3])  RiQ  [try  u  catch  p:  e5]. 

This  is  trivial. 

ii.  We  need  to  show  0(M4)  ~(;i  M2. 

This  follows  by  Lemma  31. 

Case  BRACKET-lF  ((if  [v]  then  e3  else  e4,  Mi)  -+a  ([if  v  then  e3  else  e4],  M4)): 

From  4>{ei)  rjq  e2,  we  know  that  e2  =  (if  [?/]  then  e5  else  e6).  By  BRACKET-lF, 
we  have 


(if  [n]  then  e5  else  e6,M2)  ->•  ([if  u  then  e5  else  e6],M2) . 
Choose  ()'  =  <j). 

i.  We  need  to  show  0([if  v  then  e3  else  e4])  [if  u  then  e5  else  e6]. 
This  is  trivial. 

ii.  We  need  to  show  0(M4)  M2. 

This  is  given. 


178 


Case  Bracket-Let  ((let  x  =  M  in  e3, Mi)  -»-a  ([e3{MML Mi)r  where  Vp.  v  ± 
Tp): 

From  0(ei)  »;a  e2/  we  know  that  e2  =  (let  x  =  [u]  in  e4).  If  Vp.  u  *  Lp,  then  by 
Bracket-Let,  we  have 

(let  x  =  [u]  in  e4,  M2)  ([e4{[n]/a;}],  M2) . 

Otherwise,  let  p  be  such  that  u  =  lp.  Then,  by  BRACKET-FAIL,  we  have 
(let  x  =  [ u ]  in  e4,  M2)  ->  ([lp],  M2) . 

Choose  (j)'  =  (f). 

i.  We  need  to  show  0([e3{[v]/:r}])  [e^],  where  e'{  e  {e4{[n]/x},  lp}. 

This  is  trivial. 

ii.  We  need  to  show  0(Mi)  M2. 

This  is  given. 

Case  Double-Bracket  (([[v]],  M4)  ->a  ([v],  Mi)): 

From  0(ei)  e2,  we  know  that  e2  =  [e^],  so  we  trivially  have  ([e^],  M2)  -> * 

([e2'],M2).  Choose  <£>'  =  4>. 

i.  We  need  to  show  0([v])  ~a  [e" ] - 
This  is  trivial. 

ii.  We  need  to  show  (f)(M\ )  M2. 

This  is  given. 

Case  Bracket-Context  (([ e3],M1 )  {[e3],M[),  where  (e3,  M,)  4  (e3,M[)): 

From  0(e4)  e2,  we  know  that  e2  =  [e4],  and  we  trivially  have  ([e4],  M2)  A- 

*  ([e4],  M2).  Choose  q V  =  (p. 
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i.  We  need  to  show  < p([e'3 ])  [e4]. 

This  is  trivial. 

ii.  We  need  to  show  4>(M[)  &a  M2. 

This  follows  by  Temma  31. 

Case  Bracket-Fail  ((T’[[ip]],M1)  ->q  ([ip],Mi)): 

From  0(ei)  e2/  an  easy  case  analysis  on  the  syntax  of  F[  ■  ]  shows  that 

(e2,M2)  -»•  ([l P],M2)  via  BRACKET-FAIL.  Choose  0'  =  0. 

i.  We  need  to  show  0([ip])  rjq  [ip]. 

This  is  trivial. 

ii.  We  need  to  show  0(Mx)  M2. 

This  is  given. 

Case  o-CREATE  ((ei,Mi)  -»-a  |ei,  Mi[ms  {xi  =  where  ms  is  fresh, 

_ i  i 

0;  T;  T  h -  {xi  =  [g]}5  :  RT,  T,  M[ms  {xt  =  [v*]},  and  a  $  persist (S))  : 
We  trivially  have  (e2,M2)  ->*  (e2,  M2).  Choose  0'  =  0. 

i.  We  need  to  show  0(ei)  e2. 

This  is  given. 

_ ^ 

ii.  We  need  to  show  0(Mj  [ms  >->  { xi  =  [l,]}])  ~Q  M2. 

Since  rns  /  dom(0),  this  follows  from  the  assumption  0(Mi)  »a  M2  by 
construction  of  M{. 

Case  U-ASSIGN  ((ei,Mi)  (ei,  M1[m5.xc  [v]]),  where  m5  e  dom(M1), 
Mi(m5)  *  1,  S  =  {Xi  :Ti}s,  0;  T;  T  h  [l]  :  rc,  T,  and  Mi[/ns.a:c  >->  [>]]): 

We  trivially  have  (e2,  M2)  ->*  (e2,  M2).  Choose  0'  =  0. 
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i.  We  need  to  show  4>{e\)  ~a  e2. 

This  is  given. 

ii.  We  need  to  show  ,xc  ^  [v]])  M2. 

If  ms  f.  dom(0),  then  this  follows  from  the  assumption  o{M\ )  M2 
by  construction  of  M[. 

Suppose  ms  e  dom(0).  Then  it  suffices  to  show  that  (, t>(M[(ms ))  na 
M2((j)(ms)),  since  the  rest  follows  from  o{M\ )  M2. 

Tet  ~vl,  v[,  and  be  such  that  M\(rns)  =  {xt  =  rf*}  M[(ms )  =  {a;*  =  u'} 
and  M2{;ms )  =  {xj  =  «,}.  From  RiQ  M2/  we  know  Ria  Ui  for 

all  i.  By  construction  of  M[,  we  have  v'c  =  [c]  and  /;'  =  c,  for  i  +  c. 
Therefore,  it  remains  to  be  shown  that  </>([v])  uc- 
From  0;  T;  T  i-  [c]  :  rc,  T,  we  know  that  a  $  integ(rc).  Therefore,  from 
M2,  we  must  have  uc  =  [u],  for  some  u.  The  result  4>([v])  «Q  wc 
then  follows  trivially 

Case  o-FORGET  ((ei,Mi)  -»-a  (ei,Mi[ms  i]),  where  m5  e  dom(Mi)  and  a  $ 
persist  (S')): 

We  trivially  have  (e2,M2)  ->*  (e2,M2).  Choose  0'  =  <fi. 

i.  We  need  to  show  <fi(ei)  ~Q  e2. 

This  is  given. 

ii.  We  need  to  show  (f)(M\  [rris  l])  M2. 

This  follows  from  the  assumption  c/)(Mi)  M2,  since  a  £  persist(S'). 

□ 
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3.8  Related  work 


This  chapter  identifies  and  addresses  a  new  problem,  referential  security.  As  a 
result,  little  prior  work  is  closely  related. 

Some  prior  work  has  tried  to  improve  referential  integrity  through  system 
mechanisms,  for  example  improving  the  referential  integrity  of  Web  hyper¬ 
links  [21,  39].  Systems  mechanisms  for  improving  referential  integrity  (and 
other  aspects  of  trustworthiness)  are  orthogonal  to  the  language  model  pre¬ 
sented  here,  but  could  be  used  to  justify  assigning  persistence,  integrity,  and 
authority  levels  to  nodes. 

Liblit  and  Aiken  [44]  develop  a  type  system  for  distributed  data  structures. 
Its  explicit  two-level  hierarchy  distinguishes  between  local  pointers  meaningful 
only  to  a  single  processor,  and  global  pointers  that  are  valid  everywhere.  The 
type  system  ensures  that  local  pointers  do  not  leak  into  a  global  context.  This 
work  was  extended  in  [45]  to  add  types  for  dealing  with  private  vs.  shared  data. 
However,  this  line  of  work  does  not  consider  security  properties  that  require 
defence  against  an  adversary. 

Riely  and  Hennessey  study  type  safety  in  a  distributed  system  of  partially 
trusted  mobile  agents  [67]  but  do  not  consider  referential  security. 

Our  approach  builds  on  prior  work  on  information-flow  security,  much  of 
which  is  summarized  by  [70].  The  Fabric  platform  described  in  Chapter  2  has 
a  high-level  language  that,  like  A  persist/  includes  integrity  annotations  and  ab¬ 
stracts  away  the  locations  of  objects.  Fabric  does  not  enforce  referential  security, 
however,  so  adding  the  features  described  here  is  an  obvious  next  step. 

Chugh  et  al.  [15]  develop  an  approach  to  dynamically  loading  untrusted, 
mobile  JavaScript  code  and  ensuring  that  the  code  satisfies  necessary  security 
properties.  However,  referential  security  properties  are  not  covered. 
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3.A  Appendix 


3.A.1  Full  syntax  of  \persist 


Variables 

x,y  e  Var 

Policy  levels 
PC  labels 

w,a,p,£  e  C 
pc  ::=  iv 

Memory  locations 

m  e  Mem 

Storage  labels 

s  ::=  (a,p) 

Labelled 
record  types 

S  ::=  {Xi  :  n}s 

Reference  labels 

1 

+  ~ 

II 

Labelled 

R  ::=  {Xi  :  Tj}r 

Persistence 

reference  types 

failure  handlers 

R  ::=  Pi 

Base  types 

b  ::=  bool  n  ■ 

V'  :H>  T2  ii  Soft  R 

Types  r  ::=  bw  1 

Values 

f ,  u::=  x  \  true  ■ 

false  *  mti  soft  m 

b  1  Kx  \  T)[pc-,H].e  (|  lp) 

Terms 

e  ::=  v\  V\  V2 

if  v\  then  e2  else  e 3 

{xi  =  Vi}s  v.x  V\.x  :=  V2 

soft  e  |  ei n 62  |  exists  v  as  x  :  e±  else  |  let  x  =  e\  in  e2 
try  e\  catch  p :  e2 
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3.A.2  Full  small-step  operational  semantics  for  ordinary  (non- 


adversarial)  execution  of  A 


persist 


[Apply] 

[Let] 

[If-True] 

[If-False] 

[Create] 

Parallel- 

Result 

[Assign] 


((A (x:t)\pc;T~1].  e)  v,M)  ->■  (e{v/x},M) 

Vp.  v  *  ip 

(let  x  =  v  in  e,  M)  -A  (e{v/x},M) 

(if  true  then  e\  else  e2 ,M)  -A  (e1;  M) 

(if  false  then  e\  else  e2,  M)  -A  (e2,  M ) 

m  =  newloc(M) 

({ Xi  =  v'i}s,M)  A  ( ms,M[ms  (cc;  =  A}]} 

e  M(ms )  =  {a;*  =  t/j} 

(i>iiiU2,  M)  —*•(*,  M)  [Select] 


(ms.xc,M)  A  (vc,M) 


Exists- 

True 

Exists- 


M(ms)  +  1  Vp.  v  *  Ip 
(ms .xc  :=  u,  Af)  A  (*;  M[ms.a;c  i-*  w]) 

JGI 

;ig 

M(ms)  *  i 

(exists  soft  ms  as  a: :  ei  else  e2,  M)  -A  (ei {ms /x},  M ) 
M(ms )  =  1 


Dangle- 

M(ms)  =  1  p  =  persist(ms) 

Dangle- 

M(ms)  =  1  p  =  persist(m's) 

Select 

(ms.xc,M)  -A  (ip,M) 

Assign 

(ms.xc  :=  v,  M)  -A  (ip;  M) 

[  False  J 

1  (exists  soft  ms  as  x  : 

ei  else  i 

r 

Eval-  ] 

(e,M)4(e',M'> 

Fail-’ 

[Context 

(E[e],M)  -A  (U[e'],M') 

Prop 

Soft- 

Select 


[Try-Val] 

[Try-Esc] 


(F[ip],M)4(ip,m> 


1?  ::=  soft  [•]  |  let  x  =  [•  ]  in  e  |  [  - ] lie  |  ell [  •]  |  try  [•]  catch  p:  e 
F  ::=  soft  [•]  j  let  x  =  [•]  in  e 

(ms.xc,M)  -A  (v,M)  I"  Soft-  j  (ms .xc  :=  u,M)  -A  {v',M') 

((soft  ms).xc,M)  -A  (v,M)  Assign  ((soft  ms).xc  :=  u,M)  -A  (v',M') 
Vp'.  v  *  V  [  Try-  1  p  =?  p' 

Catch 


(try  w  catch  p:  e,  M)  — ►  (i>,  M) 

_ _ 

(try  ip/  catch  p:  e,  M)  -A  (i p’,M) 


(try  ip/  catch  p:  e,  M)  — ►  (e,  M) 


[Prog-Step] 


(e,M)  — » (e',M') 
(e,M)  (e',M') 


[GC] 


gc  (G,{e,M)) 


(e,M)  ->  (e,M[Gw  i]) 
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3.A.3  Full  subtyping  rules  for  Xpersist 


[SI] 

n>  m 

-  [S2] 

H  i?l  <  /?2 

i-  {xi:ti,  . .  .,xn:Tn}r  <  {xi  :ti, 

.  .  .  ,  X  rn  ■  Tm  }  r 

1-  soft  i?i  <  soft  i?2 

i-  b\  <  b-2 

H  r2  <  Ti 

h  r[  <  T2 

[S3] 

1 -  W2  3  W  i 

-  [S4] 

^ “  (^l)u?i  —  (^2)1^2 

H  pcx  «  pc2 

pcn.'Hi  . 

H  Tl  - >  Tj  < 

pc2„H2  , 

T2  - »  T2 

[S5] 

I-  Ci-y  ^  (I2  I-  <3-2  ^  ^1 

t~P2*Pl 

I-  {Xj  .  7"j}(a|,a^,pi)  —  1^2  ‘  ^2. 

}(a+,a^,p2) 
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3.A.4  Full  typing  rules  for  A persist 


[T-Bool] 


[T-Bottom] 


[T-Parallel] 


b  e  {true,  false) 

Y;pc;R  b  :  boolT ,  T 

p  +  T  i -R4  p 


[T-Unit]  Y;pc;R\-*:l,J  [T-Var] 
wf  S  ■■  rectype 


P(*)=' 


Y;pc;R  h  1„  :  r,p 


(Vi) 


r ;  pc ;  T  h  e j :  tu1 
Y;pc;R  ei ii 62  : 1, T 


[T-LOC] 


[T-Soft] 


Y;pc;R  I-  x  :  r,  T 

S  =  {x^  •  Ti) (a,p) 


Y;pc;R  h-  mS  :  ({x,;  :  Tj(a,a;P))T,  T 
Y;pc;R  e  :  RW,X 
Y;pc;R  i-  soft  e  :  (soft  R)W,X 


Y;pc;R  i-  v  :  bool^T 


[T-If] 


r; pc  n zzj; %  i-  e, :  r,  A)  i-  auth+(r)  =S  pc  n  zu 

P ;  pc;  R  if  v  then  e\  else  e2  :  t  nw,Xin  X? 


[T-ABS] 

[T-APP] 

[T-Record] 

[T-Select] 

[T-Assign] 

T-Soft-’ 

Select 

T-Soft-’ 

Assign 

[T-Exists] 

[T-Try] 

[T-Let] 

[T-Subsume] 


T,  x-.T  ;pd ;R!  e  :  r,  R'  \-wf  (r'  P  ’H  >  r)T  :  type  i- pc' 4  pc 
Y;pc;R\-  X(x:t')[pc' ;R'].  e  :  ( r '  P  'U  >  r)T,  T 

^pc!  ^ 

Y;pc;R  I-  V\  :  (t  — ! — *■  t)w,T  T;pc;R  h  z>2  ■  t' ,T 

pc'  <  pen  w  i -R4R' 

Y;pc;R  i-z;!  v2  ■  r  n  w,  R' 

*~wf  S  :  rectype  5  =  {x.;  :  r)}(0jP)  T;  pc;  %  I-  :  t',  T  (Vl) 
i- <  Tj  i-  auth+(r()  =5  pc  i-  integ(ri)  =?  pc  i -  p  4  pc 

T;pc;R\-  {xt  =  t/i}S  :  ({x*  :  7^}(0,a,p))T,T 
Y;pc;R  h-  z> :  ({x*  T  r)}(a+a-iP))t„,  T  i-  a+  <  pc  w'  =  wnp  R  4  p 
Y;pc;R  v.xc  :  rc  nzz/,p 

T;pc;"H  \-  Vi  :  ({xt :  n}^a+ta-^)w,J  a+ 4  pc  Y;pc;R  \-  v2  :  r,T 
i-  r  n  pc  n  w  <  tc  I-  auth+(r )  ^  pc  n  w  i -R4p 

Y;pc;R  V\.xc  :=  v2  :  1  ,p 

Y;pc;Rv-v:  (soft  {x4  T  r)}(a+j0-iP))u,,  T  I-  auth+(rc)  =5  pc 
w'  =  wna~np  i -R4p 

Y;pc;R  v.xc  :  rc  nz</,p 

Y;pc;R  h  z>i  :  (soft  {x.j  :  7v}(a+>a-iP))u),T  Y;pc;R  \-  v2-t,J 
t  n  pc  n  w  4.  tc  i-  auth+(  r)  =>  pc  n  w  i -R4p 

Y;pc;R  z>i.xc  :=  z;2  :  l,p 

Y;pc;R\-  v  '■  (soft  {x*  :  T  i-  auth+(r)  =?  pc  n  w 

w'  =  auth~(r)  n  persist(r)  n  w  P,x:({xj  :  Ti}r)w;  pc  n  w';  R  \-  e\  :  r,  X\ 
Y;  pc  n  w'  ;R  e2  :  t,  X2  i-  auth+  (t)  4  penw' 

Y;pc;R  i-  exists  u  as  x  :  ei  else  e2:Tru«,,Iin  X2 
Y;pc;R,p\- e1:r,X1  w=  f]  (pup) 

p'eAi 

Y;pcnwn  integ(r);  R  e2  :  t,X2  \-  auth+(r)  pc 
Y;pc;R  \-  try  e\  catch  p:  e2  :  r  n  w,  (X1/p)  n  X2 
Y;pc;R  t-  e\  :  t\X\  i-  auth+(r')  ^  pc  zz;  =  (f~| <Ti)  n  integ(r') 
pc'=pcniu  Y,x'.t' ;pc  ;R  i-  e2  :  t, X2  auth+  (r)  ^  pc 

Y;pc;Rt-  let  x  =  ei  in  e2  :  r  n  w,  Xi  n  X2 
Y;pc;R  \-  e-r'  ,X'  i -  r  <  r  \-R4X  \- X  4  X' 

Y;pc;R\-  e:r,X 
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CHAPTER  4 


CONCLUSION 

Federated  systems  provide  new  services  and  capabilities  by  integrating  dis¬ 
tributed  information  systems  across  independent  administrative  domains.  We 
are  entering  an  era  in  which  federated  systems  are  widely  used  to  share  infor¬ 
mation  and  computation.  This  dissertation  examines  the  challenge  of  designing 
and  building  federated  information  systems  that  are  secure  and  reliable.  In  do¬ 
ing  so,  it  makes  two  key  contributions. 

The  first  contribution  is  the  design  and  implementation  of  Fabric,  a  platform 
for  building  federated  information  systems  with  confidentiality  and  integrity 
assurances.  Fabric  aims  to  make  secure  distributed  applications  easier  to  de¬ 
velop,  and  to  enable  the  secure  integration  of  information  systems  controlled 
by  different  organizations. 

The  second  contribution  is  the  identification  of  referential  security  vulnera¬ 
bilities,  which  arise  in  federated  systems  with  persistent  information.  We  for¬ 
mally  characterize  these  vulnerabilities,  and  introduce  a  high-level  language  for 
modelling,  analyzing,  and  preventing  them. 

4.1  Securely  sharing  computation  and  storage 

Chapter  2  presented  Fabric,  a  new  distributed  platform  for  general  secure  shar¬ 
ing  of  information  and  computation  resources.  Fabric  provides  a  high-level  ab¬ 
straction  for  secure,  consistent,  distributed  general-purpose  computations  using 
distributed,  persistent  information.  Persistent  information  is  conveniently  pre¬ 
sented  as  language-level  objects  connected  by  pointers.  Fabric  exposes  security 
assumptions  and  policies  explicitly  and  declaratively.  It  flexibly  supports  both 
data-shipping  and  function-shipping  styles  of  computation.  Results  from  im- 
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plementing  complex,  realistic  systems  in  Fabric,  such  as  CMS  and  SIF,  suggest 
it  has  the  expressive  power  and  performance  to  be  useful  in  practice. 

Fabric  led  to  some  technical  contributions.  Fabric  extends  the  Jif  program¬ 
ming  language  with  new  features  for  distributed  programming,  while  showing 
how  to  integrate  those  features  with  secure  information  flow.  This  integration 
requires  a  new  trust  ordering  on  information-flow  labels,  and  new  implementa¬ 
tion  mechanisms  such  as  writer  maps  and  hierarchical  two-phase  commit. 

4.2  Defining  and  enforcing  referential  security 

While  Fabric  perhaps  goes  farther  toward  the  goal  of  securely  and  transpar¬ 
ently  sharing  distributed  resources  than  prior  systems,  it  does  not  guarantee 
availability  in  the  way  that  it  does  confidentiality  and  integrity.  Chapter  3  iden¬ 
tified  formalized  a  class  of  referential  security  properties  that  is  important  for 
availability  of  distributed  systems  with  persistence,  and  showed  that  referential 
security  requirements  can  be  expressed  through  label  annotations.  It  introduced 
A persist ,  a  high-level  language  for  modelling  referential  security  issues  in  a  dis¬ 
tributed  system,  and  it  demonstrated  how  to  enforce  these  security  properties, 
through  static  analysis  expressed  as  a  type  system  for  the  language.  The  type 
system  was  validated  by  formal  proofs  that  A persist  programs  enforce  the  new 
security  properties. 

4.3  Future  work 

There  are  many  hard  problems  left  to  solve  to  make  the  task  of  building  secure, 
reliable  federated  systems  easy  enough  to  be  achievable  by  programmers  who 
are  not  security  experts. 
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The  obvious  next  step  is  to  integrate  the  features  of  A persist  with  Fabric's  lan¬ 
guage.  This  would  help  evaluate  how  well  its  types  guide  programmers  in 
designing  distributed  computing  systems. 

With  advanced  type  systems,  such  as  those  in  Fabric  and  \persist,  program¬ 
mer  annotation  burden  is  a  common  concern.  More  techniques  are  needed  for 
reducing  this  burden  while  maintaining  safety  guarantees.  For  example.  Fabric 
applications  have  Os  and  Ow  annotations  for  specifying  the  stores  on  which  to 
place  objects,  and  the  workers  on  which  to  make  remote  calls.  Inferring  these 
annotations  by  automatically  partitioning  programs  and  data,  while  maintain¬ 
ing  security  and  optimizing  performance,  is  an  interesting  problem  and  would 
reduce  annotation  burden. 

Persistent  objects  introduce  the  problem  of  schema  evolution  and  its  security 
implications.  We  have  recently  developed  support  in  Fabric  for  basic  class  evo¬ 
lution  [3].  Supporting  full  schema  evolution  securely  and  intuitively  remains  an 
open  and  difficult  problem. 

The  performance  of  Fabric  is  limited  by  its  strong  consistency  guarantees. 
Much  of  the  computational  overhead  at  the  worker  is  due  to  transaction  log¬ 
ging.  Reducing  this  overhead,  perhaps  through  a  principled  weakening  of  con¬ 
sistency  guarantees,  or  by  leveraging  recent  work  on  transactional  memory, 
would  be  valuable. 

Fabric's  hierarchical  commit  protocol  depends  on  the  availability  of  the 
transaction  coordinator.  As  discussed  in  Section  2.4.3,  Fabric  weakens  its  safety 
guarantees  for  stronger  availability  guarantees  by  timing  out  prepared  transac¬ 
tions.  Adding  consensus  mechanisms  to  the  commit  protocol  appears  to  be  a 
promising  approach  to  recovering  safety. 

Future  information  systems  must  be  secure  and  reliable  while  supporting 
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mutually  distrusting  participants.  An  important  goal  is  to  put  the  construction 
of  these  systems  within  the  reach  of  the  everyday  programmer.  Higher-level 
programming  models  are  a  key  aspect  of  attaining  this  goal,  and  this  has  been 
a  guiding  principle  of  the  work  presented  here.  I  hope  that  the  contributions  of 
this  dissertation  will  in  some  way  help  achieve  this  goal. 
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